ตั้งค่า HTTPS สำหรับเว็บไซต์แบรนด์เอง: ใบรับรอง SSL, HSTS และการแก้ไข mixed content
หนึ่ง、การเลือกใบรับรองและการต่ออายุอัตโนมัติ: ไม่ต้องซื้อใบรับรอง OV และไม่ต้องต่ออายุด้วยมือ
เว็บไซต์แบรนด์เองหลายแห่งซื้อ SSL certificate แบบเสียเงินในปีแรก พอปีที่สองลืมต่ออายุ ก็โดนเบราว์เซอร์ขึ้นคำเตือนสีแดงทันที ข้อสรุปที่ขัดกับสัญชาตญาณคือ: สำหรับเว็บไซต์แบรนด์เอง B2B แทบทั้งหมด ใบรับรอง DV ฟรีของ Let’s Encrypt ก็เพียงพอแล้ว ทั้ง OCSP stapling และเรตติ้ง A+ ก็ทำได้ ส่วนชื่อบริษัทที่โชว์เพิ่มในใบรับรอง OV แบบเสียเงินนั้นไม่มีผลที่วัดได้ต่ออัตราการแปลง
การเลือกใบรับรองมีตัวชี้วัดตายตัวแค่สองข้อ: หนึ่งคืออัลกอริทึมคีย์ เลือก ECDSA P-256 ไม่ใช่ RSA 2048 ขนาด handshake เล็กลง 40% โหลดครั้งแรกบนมือถือเร็วขึ้นประมาณ 80 มิลลิวินาที; สองคือวิธีต่ออายุ ต้องใช้ certbot หรือ acme.sh ต่ออายุอัตโนมัติ ตั้ง crontab ตรวจวันละครั้ง ห้ามต่ออายุด้วยมือเด็ดขาด อุบัติเหตุใบรับรองหมดอายุ 90% เกิดจากคนที่รับผิดชอบลาออกหรือลืม
| ประเภทใบรับรอง | ต้นทุนต่อปี | การแสดงผลบนเบราว์เซอร์ | เหมาะกับสถานการณ์ | คำแนะนำ |
|---|---|---|---|---|
| Let’s Encrypt DV ECDSA | 0 หยวน | ไอคอนกุญแจปลอดภัย ไม่มีชื่อบริษัท | เว็บไซต์แบรนด์เอง B2B แทบทั้งหมด | ตัวเลือกเริ่มต้น ต่ออายุอัตโนมัติ |
| Let’s Encrypt DV RSA | 0 หยวน | ไอคอนกุญแจปลอดภัย ไม่มีชื่อบริษัท | ต้องการรองรับอุปกรณ์เก่า | ใช้เฉพาะเมื่อมีทราฟฟิกจาก IE11 |
| ใบรับรอง OV แบบเสียเงิน | 2,000 ถึง 8,000 หยวน/ปี | ชื่อบริษัทสีเขียว | การเงิน, การชำระเงิน, ลูกค้าซื้อราคาสูง | ไม่จำเป็นไม่ต้องซื้อ |
| ใบรับรอง EV แบบเสียเงิน | 5,000 ถึง 20,000 หยวน/ปี | เครื่องหมาย EV (เบราว์เซอร์ส่วนใหญ่ยกเลิกแล้ว) | แทบไม่มีกรณีใช้งาน | ไม่แนะนำ |
ตัวอย่างสถานการณ์: เว็บไซต์ SaaS ของบริษัทหังโจวที่ออกตลาดต่างประเทศ ใช้ acme.sh ขอใบรับรอง Let’s Encrypt ตั้ง crontab เป็น 0 3 * * 1 /root/.acme.sh/acme.sh –renew -d example.com ตรวจต่ออายุอัตโนมัติทุกวันจันทร์ตี 3 พร้อมกันนั้นเพิ่มกฎในระบบมอนิเตอร์: ถ้าใบรับรองเหลืออายุน้อยกว่า 15 วันให้ส่งแจ้งเตือนผ่าน WeCom ตั้งค่าแบบนี้ครั้งเดียว เขียนเสร็จแล้วสองปีถัดไปไม่ต้องแตะอีก
โดเมนหลายชื่อและไวลด์การ์ดโดเมนจัดการอย่างไร ต้องวางแผนร่วมกับ CDN เร่งความเร็วทั่วโลก นโยบายใบรับรองของโหนด ผู้ให้บริการ CDN มักมีใบรับรอง edge มาให้ ใบรับรองต้นทางและใบรับรอง edge ต้องแยกจัดการ อย่าให้การต่ออายุใบรับรอง edge ไปพึ่งใบรับรองต้นทาง
สอง、HSTS: อัปเกรดแบบค่อยเป็นค่อยไป ไม่ต้องข้ามขั้น
HSTS (HTTP Strict Transport Security) คือ header ที่บังคับให้เบราว์เซอร์ใช้ HTTPS เท่านั้น สิ่งที่ขัดกับสัญชาตญาณคือ ยิ่งตั้ง max-age ยาวนานเท่าไร ก็ยิ่งปลอดภัย แต่ก็ยิ่งเสี่ยงมากขึ้นเท่านั้น ถ้าตั้ง max-age=31536000 ตั้งแต่ครั้งแรก ทั้ง environment ทดสอบ, subdomain staging และหลังบ้านสำหรับดูแลภายใน จะเข้าถึงผ่าน HTTP ไม่ได้ไปตลอดหนึ่งปี พอ certificate มีปัญหา เว็บล่มทั้งเว็บ
จังหวะการอัปเกรดที่ถูกต้องมีสามขั้น ขั้นแรกสัปดาห์แรกตั้ง max-age=300 (5 นาที) แล้วดูว่ามีผู้ใช้แจ้งปัญหาหรือธุรกิจผิดปกติไหม ขั้นที่สองสัปดาห์ที่ 2-4 ตั้ง max-age=86400 (1 วัน) ยืนยันว่าไม่มีปัญหา ขั้นที่สามหลังผ่านไปหนึ่งเดือนค่อยขยับเป็น max-age=31536000 (1 ปี) พร้อมเพิ่ม includeSubDomains ส่วนการส่งเข้า preload list ต้องรอช้ากว่านั้น แนะนำให้รันเสถียร 3 เดือนก่อนแล้วค่อยส่งเข้า chromium preload
| ระยะ | วิธีเขียน header HSTS | ช่วงเฝ้าดู | จุดเสี่ยง |
|---|---|---|---|
| ระดับแรก | Strict-Transport-Security: max-age=300 | 1 สัปดาห์ | แทบไม่มีความเสี่ยง ย้อนกลับได้ทุกเมื่อ |
| ระดับที่สอง | max-age=86400 | 1 เดือน | เบราว์เซอร์รุ่นเก่าบางตัวอาจไม่รองรับ |
| ระดับที่สาม | max-age=31536000; includeSubDomains | 3 เดือน | subdomain ทุกตัวต้องพร้อมใช้ HTTPS แล้ว |
| ขั้นสุดท้าย | เพิ่มคำสั่ง preload แล้วส่งไปที่ hstspreload.org | ระยะยาว | ถ้าส่งไปแล้วจะถอนออกยากมาก |
ตัวอย่างสถานการณ์ เว็บอุตสาหกรรมที่ออกตลาดต่างประเทศ มีเว็บหลัก example.com ตั้ง HTTPS แล้ว แต่ legacy.example.com ยังเป็น HTTP ถ้าใส่ includeSubDomains ไปเลยจะล็อกผู้ใช้ของ subdomain legacy ไว้ วิธีที่ถูกคือทำให้ subdomain ทุกตัวเป็น HTTPS ก่อน แล้วค่อยๆ ดัน HSTS ของเว็บหลักไปจนถึงหนึ่งปี ดูรายการ subdomain ได้จากรายงานทดสอบของ SSL Labs
HSTS กับ ฐานรากด้านการปฏิบัติตามกฎสำหรับเว็บออกตลาดต่างประเทศ ข้อกำหนดด้านความปลอดภัยในการรับส่งข้อมูลสอดคล้องกัน GDPR กำหนดให้เข้ารหัสข้อมูลส่วนบุคคลที่รับส่ง HSTS คือวิธีลงมือทางเทคนิคที่ตรงที่สุด
สาม Mixed Content: อัปเกรดอัตโนมัติพร้อมเก็บกวาดด้วยมือ สองขั้นตอน
Mixed Content คือการที่หน้า HTTPS โหลด resource ที่ใช้โปรโตคอล http:// แบ่งเป็นสองประเภท ประเภทแรก passive mixed content (รูป วิดีโอ ฟอนต์) เบราว์เซอร์จะบล็อกให้อัตโนมัติแต่ไม่แจ้ง error ประเภทที่สอง active mixed content (<script>, <iframe>, fetch, XHR) จะทำให้หน้าเว็บขึ้นแดงทันที เบราว์เซอร์ปฏิเสธที่จะโหลด ฟังก์ชันใช้งานไม่ได้ไปเลย
การแก้ไขมีสองขั้น ขั้นแรกเพิ่ม header Content-Security-Policy: upgrade-insecure-requests; เบราว์เซอร์จะเปลี่ยน request ของ resource ที่เป็น http:// ทั้งหมดในหน้าให้เป็น https:// อัตโนมัติ ขั้นนี้แก้ปัญหาได้ 80% ขั้นที่สองใช้แผง Console ใน Chrome DevTools รันดู แล้วเก็บ http:// ที่ hardcode ไว้ส่วนที่เหลือออกจากโค้ดและฐานข้อมูล โดยเฉพาะ siteurl กับ home ในตาราง wp_options ของ WordPress รวมถึงข้อมูลเก่าอย่าง <img src=”http://…”> ในบทความเก่าๆ
| ประเภท Mixed Content | การทำงานของเบราว์เซอร์ | ลำดับความสำคัญในการแก้ | วิธีแก้ไข |
|---|---|---|---|
| http://<script>或<iframe> | บล็อกทันที หน้าเว็บแจ้ง error | P0 แก้ทันที | เปลี่ยนต้นทางเป็น https หรือเปลี่ยน CDN |
| request http:// XHR/fetch | Console แจ้ง error ฟังก์ชันใช้งานไม่ได้ | P0 แก้ทันที | แก้ในโค้ดเป็น relative protocol หรือ https |
| รูปภาพ http://<img> | เบราว์เซอร์บางตัวอัปเกรดอัตโนมัติ | P1 แก้ภายในหนึ่งสัปดาห์ | ใช้ upgrade-insecure-requests เป็นตัวสำรอง |
| http:// ฟอนต์หรือภาพพื้นหลัง CSS | ล้มเหลวแบบเงียบ สไตล์หาย | P1 แก้ภายในหนึ่งสัปดาห์ | เปลี่ยนลิงก์บน CDN เป็น https |
| ลิงก์ http://<a href> | เปลี่ยนเส้นทางเป็น HTTP ไม่แจ้ง error แต่ข้อมูลรั่ว | P2 เคลียร์รายเดือน | แทนที่แบบกลุ่มใน sitemap |
กับดักที่พบบ่อยที่สุดของเว็บ WordPress คือลิงก์รูปในบทความเก่าที่ฮาร์ดโค้ดเป็น http:// ไว้ อย่าใช้ SQL แทนที่แบบกลุ่มในฐานข้อมูลโดยตรง ให้สำรองข้อมูลก่อน แล้วใช้เครื่องมือ Search Replace DB เพื่อแทนที่แบบปลอดภัยต่อ serialized data ไม่เช่นนั้นข้อมูล PHP serialized จะเสีย วิธีสำรองข้อมูลดูได้ที่การสำรองและกู้คืนเว็บไซต์。
การล้าง mixed content และ การปรับแต่ง Core Web Vitals ทำงานเชื่อมกัน สคริปต์ที่ถูกบล็อกจะทำให้ LCP ช้า และรูปที่ถูกปฏิเสธการโหลดจะทำให้เกิด CLS พอ ล้าง mixed content เสร็จ ตัวชี้วัดสองตัวนี้มักดีขึ้นเอง
สี่ เช็กลิสต์ตรวจรับและตรวจสอบรายเดือน
การตั้งค่า HTTPS ไม่ใช่ทำครั้งเดียวตอนเปิดเว็บแล้วจบ เพราะใบรับรองหมดอายุได้ ซับโดเมนใหม่เพิ่มได้ และเนื้อหาเก่านำลิงก์ http กลับเข้ามาได้ ต้องทำตารางตรวจสอบรายเดือน รันเดือนละครั้ง ใช้เวลาแค่ 5 ถึง 10 นาทีก็เสร็จ
| รายการตรวจสอบ | เครื่องมือ/วิธี | เกณฑ์ผ่าน | การจัดการกรณีไม่ผ่าน |
|---|---|---|---|
| คะแนน SSL Labs | ssllabs.com/ssltest | A หรือ A+ | ปรับการตั้งค่า TLS ปิดโปรโตคอลเก่า |
| อายุคงเหลือของใบรับรอง | openssl s_client | ≥15 วัน | ต่ออายุทันที |
| เปลี่ยนเส้นทาง HTTP ไป HTTPS | curl -I http://example.com | 301 ไป https | เพิ่ม rewrite rule |
| มีเฮดเดอร์ HSTS | ใช้ curl -I ดูเฮดเดอร์ตอบกลับ | max-age≥86400 | เพิ่มการตั้งค่าเฮดเดอร์ตอบกลับ |
| จำนวน mixed content | Chrome DevTools Console | 0 รายการ | หาและแทนที่ http ที่ฮาร์ดโค้ดไว้ |
| เวอร์ชัน TLS | รายงาน SSL Labs | ใช้เฉพาะ TLS 1.2/1.3 | ปิด TLS 1.0/1.1 |
วิธีทำระบบตรวจสอบอัตโนมัติ ดูได้ที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์ บทว่าด้วยการมอนิเตอร์ใบรับรองหมดอายุและความพร้อมใช้งาน ส่วนหลังถูกแฮก การตั้งค่า HTTPS มักเสียหาย ดูขั้นตอนการกู้คืนได้ที่การกู้คืนและทำ index ใหม่หลังเว็บถูกแฮก。
ข้อเตือนที่ขัดกับสัญชาตญาณ: อย่าเพิ่งส่ง HSTS preload ง่ายๆ เพราะเมื่อโดเมนคุณเข้าไปอยู่ในรายการ preload ที่ฝังในเบราว์เซอร์แล้ว หากอนาคตอยากถอดออกต้องผ่านขั้นตอนถอดโดยเฉพาะ และอีกหลายเดือนเบราว์เซอร์ของผู้ใช้เดิมก็ยังบังคับ HTTPS อยู่ ถ้าธุรกิจคุณยังปรับซับโดเมนและสภาพแวดล้อมทดสอบบ่อย อย่างน้อยควรรอให้เว็บหลักทำงานเสถียรสักครึ่งปีก่อนค่อยคิดเรื่อง preload
FAQ คำถามที่พบบ่อย
ใบรับรอง Let’s Encrypt ฟรีเพียงพอไหม ต้องซื้อ OV แบบเสียเงินหรือไม่
ตั้ง HSTS เป็น max-age=31536000 ตั้งแต่ครั้งแรกเลยได้ไหม
เนื้อหาผสมจะแก้เป็นชุดยังไง มีเครื่องมือกดปุ่มเดียวไหม
ต่ออายุใบรับรองอัตโนมัติตั้งยังไง กลัวพลาดตรงไหนที่สุด
HTTPS มีผลกับ SEO ไหม ต้องทำทั้งเว็บเป็น HTTPS หรือเปล่า
เวอร์ชัน TLS ต้องตั้งยังไง TLS 1.0 กับ 1.1 ควรปิดไหม
ทิ้งท้าย
เรื่องการตั้งค่า HTTPS มักถูกมองว่า “ติดตั้งใบรับรองแล้วจบ” แต่จริง ๆ แล้วมันเป็นรากฐานของความปลอดภัยและ SEO สำหรับเว็บไซต์อิสระ ปัญหาสามประเภท ได้แก่ ใบรับรองหมดอายุ ขาด HSTS และหลงเหลือ mixed content ล้วนทำให้เบราว์เซอร์ขึ้นคำเตือนสีแดงทันที ผู้ซื้อเห็นกล่องคำเตือนก็ปิดหน้าเว็บหนี และคะแนน SEO ก็ถูกลดทอนไปด้วย ตั้งค่าให้ถูกตั้งแต่ครั้งเดียว ตรวจสอบเดือนละครั้ง ต้นทุนต่ำมาก แต่ผลตอบแทนมองเห็นได้ทั้งเว็บไซต์
ลงมือทำสามขั้นตอน: เริ่มจากใช้ Let’s Encrypt ต่ออายุอัตโนมัติให้ผ่านด่านใบรับรอง แล้วรัน SSL Labs ให้ได้เกรด A ขึ้นไป จากนั้นไล่ปรับ HSTS ตามจังหวะสามระดับ จาก 5 นาทีขึ้นไปถึงหนึ่งปี สุดท้ายใช้ upgrade-insecure-requests ร่วมกับตรวจสอบด้วยมือเพื่อลด mixed content ให้เหลือ 0 ทำครบสามขั้นตอนนี้ HTTPS จึงจะถือว่าตั้งค่าเสร็จจริง รายการตรวจสอบประจำวันดูได้ที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์ แล้วใส่การตรวจสอบ HTTPS เข้าไปในนั้น
ประโยคเดียวที่จำได้ง่าย: HTTPS ไม่ใช่แค่ติดตั้งใบรับรองแล้วจบ ต้องต่ออายุใบรับรองอัตโนมัติ อัปเกรด HSTS อย่างค่อยเป็นค่อยไป และเคลียร์ mixed content ให้เหลือศูนย์ ผ่านครบทั้งสามชั้นจึงจะเป็น HTTPS ที่แท้จริง ขาดชั้นใดชั้นหนึ่ง คำเตือนสีแดงของเบราว์เซอร์จะไล่ผู้ซื้อของคุณออกไปแทน