หากเราเป็นผู้ดูแลเว็บไซต์หรือผู้ดูแลระบบที่ต้องติดตั้ง SSL Certificate อยู่บ้าง คงเคยรู้สึกว่าการต่ออายุใบรับรอง หรือที่เราเรียกกันคุ้นเคยว่า “SSL Certificate” ปีละครั้งนั้นก็วุ่นวายพออยู่แล้ว แต่ข่าวนี้อาจทำให้พวกเรางานเข้ากันได้เลย เพราะกำลังจะกลายเป็นทุก 47 วัน โดยบทความนี้จะพาไปทำความเข้าใจว่าเกิดอะไรขึ้น ทำไมต้องเปลี่ยน กระทบอะไรบ้าง และเราควรรับมืออย่างไรดี...
เกิดอะไรขึ้น?
เมื่อเดือนเมษายน ปี ค.ศ. 2025 ที่ผ่านมา องค์กรที่ชื่อว่า “CA/Browser Forum” ได้ผ่านมติลดอายุสูงสุดของ SSL/TLS Certificate ลงมาอย่างต่อเนื่อง จนเหลือเพียง 47 วัน ภายในปี 2029 โดยมติครั้งนี้ได้รับเสียงสนับสนุน 29 เสียง และไม่มีใครคัดค้านเลยแม้แต่เสียงเดียว
โดยองค์กร “CA/Browser Forum” คือกลุ่มอุตสาหกรรมที่รวบรวมทั้ง Certificate Authority (CA) ชื่อดัง ยกตัวอย่างเช่น DigiCert, GlobalSign และตัวแทนจากเว็บบราวเซอร์ยักษ์ใหญ่อย่าง Google, Apple, Mozilla และ Microsoft ที่ทำงานร่วมกันเพื่อกำหนดมาตรฐานความปลอดภัย web PKI ของโลก ซึ่งก่อนหน้านี้ SSL/TLS Certificate จะมีอายุสูงสุดอยู่ที่ 398 วัน หรือประมาณ 13 เดือน ซึ่งหลายองค์กรซื้อแบบ 1 - 2 ปีกันมาตลอด แต่ตอนนี้ระบบแบบนั้นได้สิ้นสุดลงแล้ว...
รูปแบบของการเปลี่ยนแปลง
การลดอายุ SSL/TLS certificate ไม่ได้เกิดขึ้นทันทีทีเดียว แต่จะค่อยๆ ทยอยลดลงตามลำดับดังนี้
| วันที่มีผล |
อายุสูงสุด |
หมายเหตุ |
| ก่อน มีนาคม 2026 |
398 วัน (~13 เดือน) |
หมดระยะเวลานี้แล้ว |
| 15 มีนาคม 2026 |
200 วัน (~6 เดือน) |
เฟสแรก (เริ่มใช้แล้ว) |
| 15 มีนาคม 2027 |
100 วัน (~3 เดือน) |
เฟสสอง |
| 15 มีนาคม 2029 |
47 วัน (~6 สัปดาห์) |
เป้าหมายสุดท้าย |
นอกจากอายุของ SSL/TLS Certificate แล้ว ยังมีอีกเรื่องที่กระทบไม่แพ้กัน คือระยะเวลาที่ CA จะสามารถนำหลักฐานการยืนยันโดเมน (Domain Control Validation หรือ DCV) มาใช้ซ้ำได้ จะลดลงเหลือเพียง 10 วันในปี ค.ศ. 2029 เช่นกัน แปลว่าไม่ใช่แค่ SSL/TLS Certificate จะหมดบ่อยขึ้น แต่ยังต้องยืนยันตัวตนโดเมนบ่อยขึ้นด้วย ซึ่งแค่คิดเรื่องขั้นตอนเหล่านี้ก็เหนื่อยขึ้นอีกเยอะเลย
ทำไมต้องเปลี่ยน? เหตุผลอยู่ที่ไหน?
หลายคนอาจสงสัยว่าทำไมอุตสาหกรรมถึงต้องทำแบบนี้ ในเมื่อระบบเดิมก็ใช้งานได้ดีอยู่แล้ว เหตุผลหลักๆ มีอยู่หลายข้อ สรุปเป็นหัวข้อคร่าวๆ ได้ดังนี้
- ความเสี่ยงจากการถูกขโมยกุญแจ (Key Compromise) SSL/TLS Certificate ที่มีอายุนานมีความเสี่ยงสูง เพราะถ้ามีใครแอบโจรกรรมกุญแจส่วนตัว (private key) ไป แต่กุญแจที่ใช้ในการเข้ารหัส Certificate ยังมีอายุอีก 10 เดือน ก็แปลได้ว่าโจรก็จะมีเวลาราว 10 เดือนที่จะแอบอ้างเป็นเว็บไซต์นั้นๆ ได้โดยที่ไม่มีใครรู้ แต่ถ้า SSL/TLS Certificate อายุสั้นลงเหลือ 47 วัน ความเสียหายก็จำกัดอยู่ในกรอบที่แคบลงมากอย่างเห็นได้ชัด
- ข้อมูลที่ล้าสมัย SSL/TLS Certificate ที่มีอายุยาวมากอาจยังคงใช้งานอยู่ แม้ว่าข้อมูลองค์กรหรือโดเมนจะเปลี่ยนไปแล้วก็ตาม เช่น บริษัทเปลี่ยนชื่อ บริษัทมีการควบรวมกิจการ หรือเจ้าของโดเมนเปลี่ยนมือ การต่ออายุบ่อยขึ้นหมายความว่าข้อมูลใน SSL/TLS Certificate จะมีความทันสมัยและแม่นยำมากขึ้น
- อัลกอริธึมที่ล้าสมัย (Algorithm ที่ deprecated) ในโลกของการเข้ารหัส (Cryptography) อัลกอริธึมที่ดีวันนี้อาจจะไม่ปลอดภัยในอีก 2 ปีข้างหน้าก็ได้ การกำหนดให้ SSL/TLS Certificate มีอายุสั้นลงทำให้การเปลี่ยนผ่านไปใช้อัลกอริธึมที่ทันสมัย เป็นการลดความเสี่ยงไปได้มาก โดยไม่ต้องรอให้หมดอายุก่อน
- รองรับยุค Quantum Computing การลดอายุ SSL/TLS Certificate จะช่วยให้ระบบมีความยืดหยุ่น (crypto agility) มากขึ้น พร้อมรับมือกับการเปลี่ยนผ่านสู่ยุค post-quantum cryptography ในอนาคตอันใกล้ ซึ่งนักวิทยาศาสตร์คาดว่าจะมาถึงภายในทศวรรษนี้
แล้วทำไมต้องเป็นที่ 47 วัน? มีเหตุผลอะไร
สำหรับระยะเวลา 47 วันดูเหมือนเป็นระยะเวลาที่กำหนดขึ้นมาโดยไม่มีหลักการใดๆ แต่ในความเป็นจริงแล้วเป็นระยะเวลาที่กำหนดขึ้นมาชัดเจน สามารถอธิบายได้ดังนี้
- เฟสแรกที่ระยะเวลา 200 วันมาจาก ระยะเวลา 6 เดือนที่มีจำนวนวันสูงสุดรวมกัน 184 วัน + ระยะเวลาครึ่งเดือนที่ 15 วัน + ระยะเวลาเผื่อเพิ่มเติมอีก 1 วัน
- เฟสที่สองในระยะเวลา 100 วันมาจาก ระยะเวลา 3 เดือนที่มีจำนวนวันสูงสุดรวมกัน 92 วัน + ระยะเวลาหนึ่งในสี่ของเดือนที่ 7 วัน + ระยะเวลาเผื่อเพิ่มเติมอีก 1 วัน
- เฟสสุดท้ายที่ระยะเวลา 47 วันมาจาก ระยะเวลา 1 เดือนที่มีจำนวนวันสูงสุดคือ 31 วัน + ระยะเวลาครึ่งหนึ่งของเดือน 15 วัน + ระยะเวลาเผื่อเพิ่มเติมอีก 1 วัน
- ดังนั้น ระยะเวลา 47 วัน จึงมีเหตุผลในการคำนวณได้ตามที่อธิบายด้านบนนั่นเอง
แล้วมีผลกระทบกับใครบ้าง?
ผลกระทบครั้งนี้ไม่ได้ตกหนักที่ใครคนเดียว แต่กระจายไปทั่วซึ่งจะเกี่ยวข้องกับบุคคลเหล่านี้ ได้แก่
- ทีมไอทีและผู้ดูแลระบบ (System Administrator หรือ Sysadmin) ที่ต้องดูแล SSL/TLS certificate แบบแมนนวล เป็นผู้ประสบภัยที่ได้รับผลกระทบหนักที่สุด เพราะถ้าตอนนี้มี SSL/TLS Certificate ที่ต้องดูแล 100 ชุดดูแลปีละครั้ง แต่พอเปลี่ยนเป็น 47 วัน จำนวนครั้งที่ต้อง Renew จะพุ่งขึ้นกว่า 7 เท่าเลยทีเดียว เรียกได้ว่าแทบจะทำไม่มีสิ้นสุดได้เลย
- เจ้าของเว็บไซต์ที่ใช้ SSL/TLS Certificate แบบแมนนวล ถ้ายังไม่มีระบบการทำงานแบบอัตโนมัติ (automation) ในตอนนี้เป็นเวลาที่ต้องเริ่มหาโซลูชันในการทำงานแบบอัตโนมัติได้แล้ว
- ทีม DevOps และ Cloud Engineer ต้องปรับเปลี่ยนระบบ pipeline ให้รองรับการ rotate SSL/TLS Certificate โดยอัตโนมัติ
- ผู้ให้บริการ CA อย่าง DigiCert ต้องลงทุนในโครงสร้างพื้นฐานใหม่เพื่อรองรับการออก SSL/TLS Certificate ที่ถี่ขึ้นมาก
แล้วราคา SSL จะเป็นยังไง?
เรื่องนี้ก็เกี่ยวกันอย่างหลีกเลี่ยงไม่ได้ DigiCert ซึ่งเป็นหนึ่งใน CA รายใหญ่ที่สุดของโลก ได้แจ้งปรับราคาผลิตภัณฑ์ Public Trust Certificates เฉลี่ยประมาณ 15% มีผลตั้งแต่วันที่ 10 มีนาคม ค.ศ. 2026 เป็นต้นไป ครอบคลุมผลิตภัณฑ์หลากหลาย ทั้ง SSL/TLS แบบ DV, OV, EV รวมถึง Code Signing, Document Signing, S/MIME และ VMC
โดยเหตุผลที่ระบุคือต้องลงทุนเพิ่มในการขยายโครงสร้างพื้นฐาน WebPKI ระบบอัตโนมัติสำหรับการจัดการ TLS Certificate การตรวจสอบ Domain Control Validation แบบอัตโนมัติผ่านระบบ DNS รวมถึงการปรับปรุงกระบวนการตรวจสอบ OV และ EV เพื่อรองรับความถี่ในการออก SSL/TLS Certificate ที่เพิ่มขึ้นนั่นเอง
แล้วเราควรรับมืออย่างไร?
ข่าวดีคือเรายังมีเวลาเตรียมตัว แต่ถ้ารอช้าก็อาจตามไม่ทัน เพราะเฟสแรกเริ่มมีนาคม 2026 นี้แล้ว สิ่งที่ควรทำตอนนี้มีดังนี้
- ตรวจสอบ SSL/TLS Certificate ทั้งหมดขององค์กร (Assessment) เพื่อให้เรารู้ว่ามีกี่ใบ อยู่ที่ไหนบ้าง หมดอายุเมื่อไร และใครดูแล หลายองค์กรมี SSL/TLS Certificate กระจายอยู่ในหลายระบบโดยไม่มีใครรู้ครบทั้งหมด
- เริ่มใช้ระบบอัตโนมัติ (Automation) ไม่ว่าจะเป็น ACME Protocol ที่ Let's Encrypt ใช้, DigiCert CertCentral หรือ Certificate Lifecycle Management (CLM) ของผู้ให้บริการต่างๆ การต่ออายุ SSL/TLS Certificate แบบแทนนวลจะไม่สามารถทำได้อีกต่อไปหากต้องต่ออายุทุกๆ 47 วัน
- ทดสอบระบบ pipeline ในการต่ออายุ อย่ารอให้ SSL/TLS Certificate หมดอายุแล้วค่อยทดสอบ ควรทดสอบระบบอัตโนมัติตั้งแต่ตอนนี้ เพื่อให้แน่ใจว่าทุกอย่างทำงานได้ถูกต้องก่อนที่ระยะเวลาตามแผนจะมาถึง
- ติดตามผู้ให้บริการที่ใช้อยู่ ถ้าเราใช้บริการโฮสติ้ง (hosting) หรือผู้ให้บริการคลาวด์อยู่ ลองตรวจสอบว่าเขามีแผนรองรับการเปลี่ยนแปลงนี้อย่างไร บางเจ้าอาจมีอัตโนมัติให้อยู่แล้ว
บทสรุป
การเปลี่ยนผ่านไปสู่ SSL/TLS Certificate ที่มีอายุ 47 วันเป็นการเปลี่ยนแปลงครั้งใหญ่ของวงการอินเทอร์เน็ตเลยทีเดียว แต่มีเป้าหมายที่ชัดเจน คือทำให้ระบบเว็บไซต์มีความปลอดภัยมากขึ้น ลดความเสี่ยงจากผู้ไม่หวังดีจะใช้ประโยชน์จาก SSL/TLS Certificate ที่หมดอายุหรือถูกแฮก (compromise)
สำหรับใครที่ดูแลระบบอยู่ตอนนี้ อย่ามองว่ายังมีเวลาอีก 3 ปี เพราะเฟสแรกเริ่มแล้วในปีนี้ (2026) และถ้าองค์กรมี SSL/TLS Certificate เยอะ การเตรียมตัวแต่เนิ่นๆ จะดีกว่าวิ่งไล่แก้ปัญหา SSL/TLS Certificate หมดอายุในนาทีสุดท้ายแน่นอน หรือพูดง่ายๆ ก็คือ ระบบอัตโนมัติไม่ใช่ทางเลือกอีกต่อไปแล้ว มันคือความจำเป็น (must-have) ในโลก SSL ยุคใหม่นั่นเอง
อ้างอิง: