วิธีวางระบบ HTTPS และ TLS สำหรับร้านค้าออนไลน์และ E-commerce แบบเป็นขั้นตอน

ร้านค้าที่เพิ่งเปิดใหม่หรือกำลังย้ายจากแพลตฟอร์มเดิมมักตั้งค่า HTTPS แบบเรียงลำดับผิด เช่น เปิดใช้งานใบรับรองก่อน แล้วค่อยไปนึกถึง Payment Gateway และ Redirect URL เก่าทีหลัง ผลคือระหว่างเปลี่ยนผ่านมีช่วงที่หน้าชำระเงินใช้งานไม่ได้ หรือหน้าสินค้าเดิมที่เคยติดอันดับค้นหาหายไปจากผลการค้นหาชั่วคราว

คู่มือนี้เรียงขั้นตอนตามลำดับที่ควรทำจริงสำหรับร้านค้าออนไลน์โดยเฉพาะ ครอบคลุมตั้งแต่การเตรียมข้อมูลก่อนเริ่ม ไปจนถึงขั้นตอนสุดท้ายที่มักถูกมองข้ามคือการย้าย URL เก่าโดยไม่เสียอันดับ SEO ที่สะสมมา

ก่อนเริ่ม: เตรียมข้อมูลโดเมนและ Payment Gateway ที่ใช้งาน

ก่อนแตะการตั้งค่าใด ๆ ให้รวบรวมรายชื่อโดเมนและซับโดเมนที่ร้านใช้งานจริงทั้งหมด เช่น โดเมนหลัก ซับโดเมนของระบบสมาชิก และซับโดเมนของ API หากมี รวมถึงตรวจสอบว่า Payment Gateway ที่ใช้อยู่กำหนดเงื่อนไขเฉพาะเรื่องโดเมนหรือใบรับรองหรือไม่ เพราะบาง Gateway ต้องการให้แจ้งโดเมนที่จะเชื่อมต่อไว้ล่วงหน้าในระบบของผู้ให้บริการ

ขั้นตอนที่ 1: ติดตั้งใบรับรอง TLS และเปิด HTTPS ทั้งร้าน

ติดตั้งใบรับรอง TLS ที่ครอบคลุมโดเมนหลักและซับโดเมนที่รวบรวมไว้ในขั้นตอนก่อนหน้า สำหรับร้านที่ใช้แพลตฟอร์มสำเร็จรูปอย่าง Shopify ใบรับรองมักถูกจัดการให้อัตโนมัติเมื่อผูกโดเมนของตัวเองเข้ากับระบบ ส่วนร้านที่ใช้ WooCommerce บนโฮสติ้งทั่วไป ต้องติดตั้งใบรับรองผ่านผู้ให้บริการโฮสต์หรือใช้ใบรับรองฟรีที่ต่ออายุอัตโนมัติผ่านการตั้งค่าบนเซิร์ฟเวอร์

เลือกใบรับรองฟรีหรือใบรับรองแบบชำระเงิน

ใบรับรองฟรีที่ต่ออายุอัตโนมัติเพียงพอสำหรับการเข้ารหัสข้อมูลระหว่างทางในทางเทคนิค และร้านค้าจำนวนมากใช้งานได้จริงโดยไม่มีปัญหา ส่วนใบรับรองแบบชำระเงินมักมาพร้อมช่องทางสนับสนุนจากผู้ให้บริการโดยตรงและระยะเวลาใช้งานยาวกว่าต่อครั้ง ซึ่งบางร้านเลือกใช้เพื่อลดความถี่ในการตั้งค่าซ้ำ ไม่ใช่เพราะการเข้ารหัสต่างกัน ร้านค้าควรเลือกตามความสะดวกในการดูแลของทีมตัวเอง มากกว่าเชื่อว่าใบรับรองราคาแพงกว่าจะปลอดภัยกว่า

หลังติดตั้งแล้ว ให้ตั้งค่าให้ทุกหน้าของร้านเปิดผ่าน HTTPS เป็นค่าเริ่มต้น ไม่ใช่เปิดเฉพาะหน้าตะกร้าหรือหน้าชำระเงิน เพราะข้อมูลที่ลูกค้าเรียกดูตลอดเส้นทางการช้อป เช่นสินค้าที่กำลังดูอยู่ ก็ควรเข้ารหัสระหว่างส่งเช่นกัน

ขั้นตอนที่ 2: ตั้งค่า HSTS และปิดเส้นทาง HTTP เดิม

เปิดใช้งาน HTTP Strict Transport Security เพื่อบอกเบราว์เซอร์ให้เชื่อมต่อร้านผ่าน HTTPS เสมอโดยไม่ต้องรอ Redirect จาก HTTP ก่อน ซึ่งช่วยตัดช่องโหว่ในช่วงเสี้ยววินาทีที่เบราว์เซอร์ยังเชื่อมต่อผ่าน HTTP อยู่ ก่อนถูก Redirect ไป HTTPS

จากนั้นตั้งค่า Redirect ทุกคำขอที่เข้ามาผ่าน HTTP ให้ไปยัง HTTPS ด้วยสถานะ 301 ทั้งหมด รวมถึงคำขอที่มาจากพอร์ต HTTP มาตรฐาน ไม่ใช่แค่หน้าแรกของร้าน ให้ทดสอบด้วยการพิมพ์ URL แบบ http:// ของหน้าสินค้าและหน้าตะกร้าโดยตรงเพื่อยืนยันว่า Redirect ทำงานครบทุกเส้นทาง

ขั้นตอนที่ 3: เชื่อมต่อ Payment Gateway ผ่าน HTTPS และตรวจ iframe ของผู้ให้บริการชำระเงิน

เชื่อมต่อ Payment Gateway ตามคู่มือของผู้ให้บริการ โดยยืนยันว่า Callback URL หรือ Webhook URL ที่ตั้งค่าไว้ในระบบของ Gateway ชี้ไปที่ https:// ของร้านทั้งหมด ไม่ใช่ URL แบบ http:// ที่หลงเหลือจากการตั้งค่าครั้งแรก

หากใช้ iframe หรือ Redirect ไปยังหน้าชำระเงินของผู้ให้บริการภายนอก ให้เปิดหน้าชำระเงินจริงแล้วตรวจว่าแถบที่อยู่ของเบราว์เซอร์ยังคง HTTPS ตลอดเส้นทาง ไม่มีจังหวะที่หลุดไปเป็น HTTP แม้เพียงชั่วขณะระหว่างการ Redirect

ขั้นตอนที่ 4: แก้ Mixed Content บนธีมร้านค้าและแอปเสริม

เปิดทุกหน้าหลักของร้าน ได้แก่ หน้าแรก หน้าหมวดหมู่สินค้า หน้ารายละเอียดสินค้า หน้าตะกร้า และหน้าชำระเงิน แล้วตรวจว่าไม่มีคำเตือน Mixed Content จากรูปภาพ ฟอนต์ หรือสคริปต์ที่ยังอ้างอิง http:// สำหรับร้านที่ใช้ธีมสำเร็จรูป ปัญหาส่วนใหญ่มักมาจากรูปภาพพื้นหลังที่ฝังไว้ในไฟล์ตั้งค่าธีม หรือฟอนต์ที่ดึงจากบริการภายนอกด้วยลิงก์เก่า

สำหรับแอปเสริมที่ติดตั้งเพิ่ม เช่นแอปรีวิวสินค้า แอปแชทสด หรือแอปนับถอยหลังโปรโมชัน ให้ตรวจทีละแอปว่าสคริปต์ที่โหลดมาอ้างอิง https:// ทั้งหมด แอปที่พัฒนามานานอาจยังมีเวอร์ชันเก่าที่ฝังลิงก์แบบ http:// ไว้ในโค้ด

ทดสอบบน Staging ก่อนเผยแพร่จริง

ก่อนเปิดใช้งานการเปลี่ยนแปลงบนเว็บไซต์จริง ให้ทดสอบขั้นตอนที่ 3 และ 4 บนสภาพแวดล้อม Staging ก่อน โดยเฉพาะการเชื่อมต่อ Payment Gateway เพราะบาง Gateway แยก Callback URL ของ Staging และ Production ออกจากกัน การทดสอบบน Staging ช่วยให้พบปัญหา Mixed Content หรือ Callback URL ผิดพลาด ก่อนที่ลูกค้าจริงจะเจอ ไม่ใช่มาพบปัญหาตอนลูกค้ากำลังจะจ่ายเงินบนร้านจริง

ขั้นตอนที่ 5: Redirect URL เก่าจากยุค HTTP เพื่อรักษาอันดับ SEO

ทำแผนที่ Redirect จาก URL เก่าไปยัง URL ใหม่ให้ครบทุกหน้าสินค้าและหน้าบทความที่เคยติดอันดับการค้นหา ไม่ใช่แค่ Redirect หน้าแรกแล้วปล่อยให้หน้าอื่นขึ้นหน้าแจ้งข้อผิดพลาด เพราะ URL เก่าที่เคยถูกเก็บไว้ในดัชนีของเครื่องมือค้นหาจะยังมีผู้ใช้คลิกเข้ามาอยู่ระยะหนึ่งหลังเปลี่ยนแปลง

ตรวจสอบไฟล์แผนผังเว็บไซต์ (Sitemap) ให้อัปเดตเป็น URL แบบ https:// ทั้งหมด และส่งแผนผังเว็บไซต์ใหม่เข้าเครื่องมือของผู้ให้บริการค้นหาที่ร้านใช้ตรวจสอบสถานะเว็บไซต์อยู่ เพื่อให้ระบบรับรู้การเปลี่ยนแปลงเร็วขึ้น

ขั้นตอนที่ 6: ตั้งระบบแจ้งเตือนก่อนใบรับรองหมดอายุและตรวจสอบ TLS เป็นระยะ

การติดตั้งใบรับรองและเปิด HTTPS ทั้งร้านในขั้นตอนแรกเป็นจุดเริ่มต้นเท่านั้น ร้านค้าจำนวนไม่น้อยตั้งค่าเสร็จแล้วไม่เคยกลับมาตรวจซ้ำ จนกระทั่งใบรับรองหมดอายุกะทันหันและหน้าร้านขึ้นคำเตือนความปลอดภัยให้ลูกค้าเห็นโดยไม่มีใครในทีมทราบล่วงหน้า ปัญหานี้ป้องกันได้ง่ายกว่าการแก้ไขหลังเกิดเหตุมาก เพียงวางระบบแจ้งเตือนและกำหนดผู้รับผิดชอบตรวจสอบเป็นระยะตั้งแต่ตอนติดตั้งครั้งแรก

ตั้งปฏิทินแจ้งเตือนล่วงหน้าก่อนใบรับรองหมดอายุ

สำหรับร้านที่ใช้ใบรับรองแบบต่ออายุอัตโนมัติผ่านผู้ให้บริการโฮสติ้งหรือแพลตฟอร์มสำเร็จรูป การต่ออายุมักเกิดขึ้นเบื้องหลังโดยไม่ต้องมีคนเข้าไปกดต่อเอง แต่ทีมควรตั้งปฏิทินแจ้งเตือนล่วงหน้าอย่างน้อยสามสิบวันก่อนวันหมดอายุที่ระบุไว้บนใบรับรองไว้เป็นระบบสำรอง เผื่อกรณีที่การต่ออายุอัตโนมัติล้มเหลวจากสาเหตุอื่น เช่นการเปลี่ยนแปลงการตั้งค่า DNS ที่กระทบการยืนยันตัวตนโดเมน ร้านที่ใช้ใบรับรองแบบต้องต่ออายุด้วยตนเองยิ่งต้องตั้งการแจ้งเตือนให้ชัดเจน เพราะไม่มีระบบอัตโนมัติมาช่วยสำรองให้เหมือนแบบแรก

ตรวจเวอร์ชัน TLS ที่เซิร์ฟเวอร์รองรับหลังเปลี่ยนผู้ให้บริการโฮสติ้ง

ทุกครั้งที่ย้ายผู้ให้บริการโฮสติ้งหรือเปลี่ยนเซิร์ฟเวอร์ ให้ตรวจซ้ำว่าเซิร์ฟเวอร์ใหม่ยังรองรับเวอร์ชัน TLS ที่เบราว์เซอร์และอุปกรณ์ของลูกค้าส่วนใหญ่ใช้งานอยู่ เพราะการตั้งค่าเริ่มต้นของผู้ให้บริการแต่ละรายไม่เหมือนกัน บางรายอาจปิดเวอร์ชันเก่าไว้เป็นค่าเริ่มต้นซึ่งดีต่อความปลอดภัย แต่บางรายยังเปิดเวอร์ชันเก่าค้างไว้โดยไม่ได้แจ้งลูกค้า การตรวจสามารถทำได้ด้วยเครื่องมือตรวจสอบใบรับรองออนไลน์ที่เชื่อถือได้ ซึ่งมักแสดงรายการเวอร์ชัน TLS ที่เซิร์ฟเวอร์ตอบรับให้เห็นชัดเจน หากพบว่ายังเปิดเวอร์ชันเก่าที่ไม่ปลอดภัยอยู่ ให้ประสานผู้ให้บริการโฮสติ้งเพื่อปิดการใช้งานเวอร์ชันนั้น โดยเฉพาะร้านค้าที่รับชำระเงินผ่านบัตรเครดิตซึ่งมักมีข้อกำหนดเรื่องเวอร์ชัน TLS ขั้นต่ำจากผู้ให้บริการ Payment Gateway อยู่แล้ว กำหนดให้ทีมเทคนิคเป็นผู้รับผิดชอบตรวจสอบทั้งสองเรื่องนี้เป็นรอบประจำ ไม่ใช่รอให้เกิดปัญหาก่อนแล้วค่อยตามแก้

คำถามที่พบบ่อย

ต้องเรียงลำดับขั้นตอนตามที่แนะนำเป๊ะ ๆ หรือสลับได้บ้าง ควรเรียงตามลำดับนี้เพราะแต่ละขั้นตอนอ้างอิงผลจากขั้นตอนก่อนหน้า เช่นการเชื่อมต่อ Payment Gateway ควรทำหลังจากเปิด HTTPS ทั้งร้านแล้วเท่านั้น หากสลับลำดับอาจต้องตั้งค่า Callback URL ซ้ำสองรอบโดยไม่จำเป็น

ร้านที่ใช้แพลตฟอร์มสำเร็จรูปต้องทำทุกขั้นตอนเองหรือไม่ แพลตฟอร์มสำเร็จรูปหลายเจ้าจัดการใบรับรองและ HSTS ให้อัตโนมัติ แต่ขั้นตอนตรวจ Mixed Content จากแอปเสริมและการทำแผนที่ Redirect URL เก่ายังเป็นหน้าที่ของเจ้าของร้านที่ต้องตรวจเอง เพราะเป็นเรื่องเนื้อหาเฉพาะร้าน ไม่ใช่การตั้งค่าระดับแพลตฟอร์ม

ระหว่างเปลี่ยนผ่านควรปิดร้านชั่วคราวหรือไม่ ไม่จำเป็นสำหรับขั้นตอนติดตั้งใบรับรองและ HSTS ซึ่งทำได้โดยไม่กระทบผู้ใช้ แต่ควรเลือกช่วงเวลาที่มีการเข้าชมน้อยสำหรับขั้นตอนทดสอบ Payment Gateway และการย้าย Redirect URL เพื่อลดผลกระทบหากพบปัญหาระหว่างทาง

เช็กลิสต์ปฏิบัติ

• รวบรวมรายชื่อโดเมนและซับโดเมนที่ร้านใช้งานจริงทั้งหมดก่อนเริ่ม
• ติดตั้งใบรับรอง TLS ครอบคลุมทุกโดเมนและเปิด HTTPS เป็นค่าเริ่มต้นทั้งร้าน
• ตั้งค่า HSTS และ Redirect จาก HTTP ไป HTTPS ด้วยสถานะ 301 ทุกเส้นทาง
• อัปเดต Callback URL และ Webhook URL ของ Payment Gateway ให้เป็น https:// ทั้งหมด
• ทดสอบเส้นทางไปยังหน้าชำระเงินของผู้ให้บริการภายนอกว่าไม่หลุดเป็น HTTP ระหว่างทาง
• ตรวจ Mixed Content บนหน้าแรก หน้าหมวดหมู่ หน้าสินค้า ตะกร้า และหน้าชำระเงิน
• ตรวจแอปเสริมทุกตัวว่าสคริปต์ที่โหลดอ้างอิง https:// ทั้งหมด
• ทำแผนที่ Redirect จาก URL เก่าไปยัง URL ใหม่ให้ครบทุกหน้าสินค้าและบทความ
• อัปเดตไฟล์ Sitemap เป็น https:// และส่งเข้าเครื่องมือของผู้ให้บริการค้นหา

ข้อผิดพลาดที่พบบ่อย

• เชื่อมต่อ Payment Gateway ก่อนเปิด HTTPS ทั้งร้าน ทำให้ต้องแก้ Callback URL ซ้ำ
• ลืมอัปเดต Webhook URL ในระบบของ Payment Gateway จาก http:// เป็น https:// หลังเปลี่ยนแปลง
• ตรวจ Mixed Content เฉพาะหน้าแรก โดยไม่ตรวจหน้าตะกร้าและหน้าชำระเงินซึ่งเป็นจุดเสี่ยงสูงสุด
• ทำ Redirect URL เก่าเฉพาะหน้าแรก ปล่อยให้หน้าสินค้าและบทความเก่าขึ้นหน้าแจ้งข้อผิดพลาด
• ลืมอัปเดตไฟล์ Sitemap หลังเปลี่ยนเป็น HTTPS ทำให้เครื่องมือค้นหายังอ้างอิง URL เก่า

สรุป

การวางระบบ HTTPS และ TLS ให้ร้านค้าออนไลน์ต้องทำเป็นลำดับ เพราะแต่ละขั้นตอนต่อเนื่องกัน ตั้งแต่ติดตั้งใบรับรองและเปิด HTTPS ทั้งร้าน ไปจนถึงเชื่อมต่อ Payment Gateway แก้ Mixed Content บนธีมและแอปเสริม แล้วจึงย้าย URL เก่าเพื่อรักษาอันดับการค้นหา การข้ามลำดับหรือทำเพียงบางขั้นตอนมักทำให้ต้องย้อนกลับมาแก้ซ้ำในภายหลัง

แหล่งข้อมูลอ้างอิง

• OWASP HTTP Security Response Headers Cheat Sheet
• ศูนย์ความรู้ด้านความปลอดภัยเว็บไซต์ของ trusty
• เช็กลิสต์ HTTPS และ TLS สำหรับร้านค้าออนไลน์
• วิธี Audit HTTPS และ TLS ของร้านค้าออนไลน์พร้อม Evidence ที่ควรเก็บ