สรุปสั้น
Let’s Encrypt ผู้ให้บริการออกใบรับรอง (Certificate Authority: CA) แบบเปิดที่ออกใบรับรอง TLS ให้เว็บไซต์จำนวนมากที่สุดในโลก ประกาศว่าตั้งแต่วันที่ 10 กุมภาพันธ์ 2570 ใบรับรองที่ออกใหม่หรือต่ออายุทุกใบจะมีอายุ 64 วันเป็นค่าเริ่มต้น แทน 90 วันที่ใช้มายาวนาน ซึ่งเป็นขั้นแรกก่อนจะลดลงเหลือ 45 วันในปี 2571 ตามแผนที่ประกาศไว้เมื่อธันวาคม 2568 ใบรับรองอายุ 90 วันใบสุดท้ายจะหมดอายุราววันที่ 11 พฤษภาคม 2570 และ CA ที่เบราว์เซอร์เชื่อถือทุกรายจะต้องปรับแบบเดียวกันตามเกณฑ์ Baseline Requirements ของ CA/Browser Forum
การเปลี่ยนแปลงนี้ไม่ใช่ช่องโหว่ แต่เป็นจุดที่ระบบใช้งานจริงพังได้ง่าย ระบบที่ต่ออายุอัตโนมัติด้วย ACME client ที่รองรับ ACME Renewal Info (ARI) จะไม่ต้องทำอะไร เพราะ Let’s Encrypt เป็นผู้บอกจังหวะต่ออายุเอง แต่ระบบที่ตั้งวันต่ออายุตายตัว เช่น สคริปต์ที่ต่ออายุเมื่อเหลือ 30 วัน หรือใบรับรองที่ติดตั้งด้วยมือบนอุปกรณ์เครือข่าย มีโอกาสที่ใบรับรองหมดอายุก่อนรอบต่ออายุมาถึง Let’s Encrypt เริ่มออกใบรับรอง 64 วันในระบบ staging ตั้งแต่สัปดาห์นี้ให้ทดสอบล่วงหน้า และยังจะลดระยะเวลานำผลยืนยันโดเมนกลับมาใช้ซ้ำ (authorization reuse) เหลือ 10 วันในปีหน้า และ 7 ชั่วโมงในปี 2571
รายละเอียดข่าว
เว็บไซต์ SecurityWeek รายงานเมื่อวันที่ 12 ตุลาคม 2569 ว่า Let’s Encrypt เริ่มขั้นตอนแรกของการลดอายุใบรับรองที่ตนออก โดยอ้างอิงประกาศของ Let’s Encrypt เมื่อสัปดาห์ก่อน ที่ระบุว่าหลังวันที่ 10 กุมภาพันธ์ 2570 ใบรับรองที่ออกใหม่หรือต่ออายุทั้งหมดจะมีอายุ 64 วัน
แผนการลดอายุนี้ Let’s Encrypt เปิดเผยครั้งแรกในบล็อกเมื่อธันวาคม 2568 ซึ่งกำหนดเป้าหมายสุดท้ายที่ใบรับรองอายุ 45 วันในปี 2571 และระบุว่า CA ที่ได้รับความเชื่อถือสาธารณะทุกรายจะต้องเปลี่ยนแปลงในทำนองเดียวกัน ตามเกณฑ์ Baseline Requirements ของ CA/Browser Forum ที่ทยอยลดอายุสูงสุดของใบรับรองลงเป็นขั้นบันได
เหตุผลด้านความปลอดภัยที่ Let’s Encrypt และ CA/Browser Forum ระบุคือ ใบรับรองอายุสั้นทำให้การเพิกถอน (revocation) มีประสิทธิภาพขึ้น และจำกัดขอบเขตความเสียหายเมื่อกุญแจส่วนตัว (private key) หรือใบรับรองรั่ว เพราะใบรับรองที่หลุดไปจะใช้งานได้ในช่วงเวลาที่สั้นลงแม้การเพิกถอนจะไม่ทำงาน ซึ่งในทางปฏิบัติเบราว์เซอร์จำนวนมากตรวจสถานะการเพิกถอนได้ไม่สมบูรณ์
Let’s Encrypt แนะนำว่า หากระบบต่ออายุอัตโนมัติและ ACME client รองรับ ARI ก็ไม่ต้องปรับอะไร เพราะ ARI ให้ CA บอก client ได้ว่าควรต่ออายุเมื่อใด ผู้ดูแลระบบควรเช็กเอกสารของ ACME client ที่ใช้ว่ารองรับ ARI หรือไม่ ส่วนระบบที่ฮาร์ดโค้ดการต่ออายุไว้ที่จำนวนวันก่อนหมดอายุ ควรตั้งใหม่ให้ต่ออายุเมื่อผ่านไปราวสองในสามของอายุใบรับรอง
อีกการเปลี่ยนแปลงที่สำคัญคือระยะเวลานำผลการยืนยันความเป็นเจ้าของโดเมน (authorization) กลับมาใช้ซ้ำ ซึ่งจะลดเหลือ 10 วันในปีหน้า และ 7 ชั่วโมงในปี 2571 Let’s Encrypt อธิบายว่าเพื่อให้สอดคล้องกับข้อกำหนดที่จะลดระยะเวลานำผลยืนยันกลับมาใช้ซ้ำสูงสุดในปี 2572 และเพื่อตัดขั้นตอน “CAA rechecking” ที่ต้องทำซ้ำเมื่อข้อมูลยืนยันมีอายุเกิน 7 ชั่วโมง ทั้งนี้ Let’s Encrypt ยืนยันว่าการเปลี่ยนแปลงนี้ไม่กระทบ ACME endpoint สายการออกใบรับรอง (issuance chain) และเกณฑ์จำกัดอัตรา (rate limit)
รายละเอียดการเปลี่ยนแปลง
| รายการ | ปัจจุบัน | หลัง 10 ก.พ. 2570 | ปี 2571 |
|---|---|---|---|
| อายุใบรับรองเริ่มต้น | 90 วัน | 64 วัน | 45 วัน |
| ระยะนำผลยืนยันโดเมนกลับมาใช้ซ้ำ | ตามเกณฑ์เดิม | 10 วัน (ภายในปี 2570) | 7 ชั่วโมง |
| ใบ 90 วันใบสุดท้ายหมดอายุ | — | ราว 11 พ.ค. 2570 | — |
| ACME endpoint / issuance chain / rate limit | — | ไม่เปลี่ยน | — |
ผลในทางปฏิบัติของใบรับรอง 64 วันคือรอบการต่ออายุถี่ขึ้น หากต่ออายุที่สองในสามของอายุตามคำแนะนำ ระบบจะต่ออายุราวทุก 42 วัน แทนที่จะเป็นราวทุก 60 วันในยุค 90 วัน และเมื่อเหลือ 45 วัน รอบต่ออายุจะเหลือราว 30 วัน ช่วงกันชน (buffer) ระหว่างรอบต่ออายุกับวันหมดอายุจะสั้นลงตามไปด้วย ทำให้ปัญหาที่เคยมีเวลาแก้หลายสัปดาห์ เช่น ACME client หยุดทำงาน DNS challenge ล้มเหลว หรือไฟร์วอลล์บล็อก HTTP-01 challenge กลายเป็นเหตุใบรับรองหมดอายุได้เร็วขึ้น
การลดระยะนำผลยืนยันโดเมนกลับมาใช้ซ้ำเหลือ 7 ชั่วโมงในปี 2571 หมายความว่าแทบทุกครั้งที่ต่ออายุจะต้องยืนยันความเป็นเจ้าของโดเมนใหม่ ระบบที่พึ่ง DNS-01 challenge ผ่าน API ของผู้ให้บริการ DNS จะต้องให้ API นั้นพร้อมใช้งานทุกรอบ และระบบที่ยืนยันโดเมนด้วยมือครั้งเดียวแล้วออกใบรับรองหลายใบตามมาจะใช้วิธีนั้นไม่ได้อีก
ผลกระทบ
ผู้ที่ได้รับผลกระทบมากที่สุดไม่ใช่เว็บไซต์ที่ใช้ certbot หรือ ACME client รุ่นใหม่ที่ต่ออายุอัตโนมัติอยู่แล้ว แต่เป็นระบบที่อยู่นอกเส้นทางอัตโนมัติ ได้แก่ อุปกรณ์เครือข่าย load balancer ไฟร์วอลล์ อุปกรณ์ IoT หรือแอปพลิเคชันรุ่นเก่าที่ติดตั้งใบรับรองด้วยมือ สคริปต์ต่ออายุที่เขียนเองโดยตั้งค่าตายตัวไว้ที่ 30 วันก่อนหมดอายุ และระบบที่คัดลอกใบรับรองจากเครื่องหนึ่งไปติดตั้งหลายเครื่องด้วยขั้นตอนที่ไม่อัตโนมัติ ระบบเหล่านี้มีโอกาสเกิดเหตุใบรับรองหมดอายุจนบริการล่มสูงขึ้นเมื่อรอบต่ออายุถี่ขึ้น
ในภาพรวม การเปลี่ยนแปลงนี้ไม่ใช่ทางเลือกของ Let’s Encrypt รายเดียว CA สาธารณะทุกรายต้องทยอยลดอายุใบรับรองตามเกณฑ์ CA/Browser Forum เช่นกัน องค์กรที่ซื้อใบรับรองจาก CA เชิงพาณิชย์จึงจะเจอปัญหาเดียวกันในกรอบเวลาใกล้เคียง และใบรับรองที่ต้องต่ออายุด้วยมือจะกลายเป็นภาระงานที่ไม่ยั่งยืน การทำบัญชีใบรับรองทั้งหมด (certificate inventory) และย้ายไปใช้การต่ออายุอัตโนมัติจึงเป็นงานที่ควรเริ่มก่อนกุมภาพันธ์ 2570
คำแนะนำ
- ทำบัญชีใบรับรองทั้งหมดที่ออกจาก Let’s Encrypt และ CA อื่น ระบุว่าใบไหนต่ออายุอัตโนมัติ ใบไหนต่ออายุด้วยมือ และติดตั้งอยู่บนระบบใดบ้าง
- เช็กว่า ACME client ที่ใช้ (certbot, acme.sh, lego, Caddy, Traefik, cert-manager ฯลฯ) รองรับ ARI หรือไม่ และอัปเดตเป็นเวอร์ชันที่รองรับ
- ระบบที่ตั้งวันต่ออายุตายตัว ให้ปรับเป็นต่ออายุเมื่อผ่านไปราวสองในสามของอายุใบรับรอง แทนการนับถอยหลังจำนวนวันคงที่
- ทดสอบกับระบบ staging ของ Let’s Encrypt ซึ่งเริ่มออกใบรับรอง 64 วันแล้ว ก่อนการเปลี่ยนแปลงจะเข้าสู่ production
- ตั้งระบบเฝ้าระวังวันหมดอายุใบรับรองแยกจากระบบต่ออายุ (เช่น monitoring จากภายนอก) ให้แจ้งเตือนเมื่อใบรับรองเหลือน้อยกว่า 14 วัน
- วางแผนรองรับการยืนยันโดเมนทุกครั้งที่ต่ออายุ โดยเฉพาะระบบที่ใช้ DNS-01 challenge ให้ API ของผู้ให้บริการ DNS พร้อมใช้งานเสมอ
- สำหรับอุปกรณ์ที่ไม่รองรับ ACME ให้หาวิธีจัดการใบรับรองแบบรวมศูนย์ หรือวางระบบไว้หลัง reverse proxy ที่ต่ออายุอัตโนมัติได้