Certificate Lifecycle Management เมื่อใบรับรองเหลือ 47 วัน

ใบรับรองดิจิทัล (certificate) คือไฟล์ที่ใช้ยืนยันว่าเว็บไซต์หรือระบบหนึ่ง ๆ เป็นของจริง และช่วยให้การเชื่อมต่อถูกเข้ารหัส ใบรับรองสาธารณะ คือใบรับรองเว็บที่ออกโดย CA (ผู้ออกใบรับรอง) ซึ่งเบราว์เซอร์เชื่อถือ ใบรับรองแบบนี้กำลังมีอายุสั้นลงมาก ตอนนี้อายุสูงสุดคือ 200 วัน (ตั้งแต่ 15 มีนาคม 2026) จะเหลือ 100 วันในวันที่ 15 มีนาคม 2027 และเหลือ 47 วัน หรือประมาณเดือนครึ่ง ในวันที่ 15 มีนาคม 2029 กติกานี้มาจากมติ SC-081v3 ของ CA/Browser Forum (กลุ่มที่ CA และผู้พัฒนาเบราว์เซอร์ร่วมกันกำหนดข้อกำหนดของใบรับรอง) เมื่ออายุสั้นขนาดนี้ การต่ออายุด้วยมือแทบทำไม่ไหว บทความนี้จึงอธิบายการจัดการวงจรชีวิตใบรับรอง (certificate lifecycle management หรือ CLM) คือการดูแลใบรับรองตั้งแต่ค้นหา ขอ ติดตั้ง เฝ้าดู ต่ออายุ จนถึงเลิกใช้ โดยทำเป็นอัตโนมัติให้มากที่สุด

ใบรับรองทำหน้าที่อะไร และเกิดอะไรขึ้นเมื่อหมดอายุ

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

อะไรกำลังเปลี่ยน และเมื่อไร

กติกาของ CA/Browser Forum (เรียกว่า Baseline Requirements) กำหนดอายุสูงสุดของใบรับรองสาธารณะ รายการด้านล่างใช้กับใบรับรองที่ออกตั้งแต่วันที่ระบุเป็นต้นไป ก่อนออกใบรับรองทุกครั้ง CA ต้องให้เราพิสูจน์ว่าควบคุมโดเมนนั้นจริง (domain validation) ผลการพิสูจน์นี้เก็บไว้ใช้ซ้ำได้ช่วงหนึ่ง รายการจึงบอกด้วยว่าใช้ซ้ำได้กี่วัน

• ตั้งแต่ 15 มีนาคม 2026: ใบรับรองอายุได้สูงสุด 200 วัน และใช้ผลการพิสูจน์โดเมนเดิมซ้ำได้ไม่เกิน 200 วัน
• ตั้งแต่ 15 มีนาคม 2027: อายุสูงสุด 100 วัน และใช้ผลการพิสูจน์โดเมนเดิมซ้ำได้ไม่เกิน 100 วัน
• ตั้งแต่ 15 มีนาคม 2029: อายุสูงสุด 47 วัน และใช้ผลการพิสูจน์โดเมนเดิมซ้ำได้ไม่เกิน 10 วันเท่านั้น

มตินี้ผ่านเมื่อเดือนเมษายน 2025 โดยผู้ออกใบรับรอง 25 รายเห็นด้วย ไม่มีผู้ไม่เห็นด้วย และงดออกเสียง 5 ราย ส่วนผู้พัฒนาเบราว์เซอร์ทั้ง 4 ราย (Apple, Google, Microsoft และ Mozilla) เห็นด้วยทั้งหมด กติกานี้ใช้กับใบรับรองสาธารณะ ส่วนใบรับรองที่องค์กรออกเองจาก CA ของตัวเอง (ไม่ใช่ CA ที่เบราว์เซอร์เชื่อถือ) ไม่ต้องทำตามวันที่เหล่านี้ แต่การทำให้อัตโนมัติก็ยังช่วยได้ นอกจากนี้ CA ที่เราใช้อาจลดอายุใบรับรองเร็วกว่าวันที่ของ Forum จึงควรอ่านประกาศของ CA ด้วย

ทำไมวงการจึงทำเช่นนี้

ตามที่มติระบุ ใบรับรองที่อายุสั้นลงให้ประโยชน์ดังนี้

• ข้อมูลในใบรับรองใหม่อยู่เสมอ: ใบรับรองถูกเปลี่ยนบ่อย ข้อมูลในใบจึงตรงกับความเป็นจริงมากขึ้น และมีใบที่ข้อมูลล้าสมัยค้างอยู่น้อยลง
• ความเสียหายจากความผิดพลาดอยู่ได้สั้นลง: ถ้ามีการออกใบรับรองผิด หรือกุญแจส่วนตัว (private key ไฟล์ลับที่ใช้คู่กับใบรับรอง) รั่วไหล ใบรับรองนั้นจะใช้ได้ไม่นาน
• การเพิกถอนอย่างเดียวไม่เพียงพอ: การเพิกถอนคือการประกาศยกเลิกใบรับรองก่อนหมดอายุ (ผ่านบริการ CRL และ OCSP) มติระบุว่าวิธีนี้ยังมีข้อจำกัดเมื่อใช้ในระบบขนาดใหญ่ เชื่อถือได้ไม่เต็มที่ และกระทบผู้ใช้
• เปลี่ยนวิธีเข้ารหัสได้เร็ว: ถ้าวิธีเข้ารหัสเก่าใช้ไม่ได้แล้ว ก็ทยอยเปลี่ยนได้เร็ว เพราะใบรับรองหมุนเวียนบ่อย
• เกิดระบบอัตโนมัติมากขึ้น: มติระบุว่าเป็นผลพลอยได้ เพราะเมื่อต้องต่ออายุบ่อย องค์กรจะหันมาทำให้อัตโนมัติ

47 วันหมายถึงงานเพิ่มเท่าไร

ก่อน 15 มีนาคม 2026 อายุสูงสุดคือ 398 วัน ใบรับรองจึงเปลี่ยนประมาณปีละครั้ง ที่อายุสูงสุด 200 วันอย่างตอนนี้ จะเปลี่ยนประมาณ 1.8 ครั้งต่อปี ที่ 100 วันประมาณ 3.7 ครั้ง และที่ 47 วันอย่างน้อย 7.8 ครั้ง (คำนวณจาก 365 หารด้วยอายุใบรับรอง) ในทางปฏิบัติ Let's Encrypt (ผู้ออกใบรับรองรายหนึ่ง) แนะนำให้ต่ออายุเมื่อผ่านไปประมาณสองในสามของอายุ ซึ่งสำหรับ 47 วันคือทุกราว 31 วัน หรือประมาณ 11.6 ครั้งต่อปี (365 หารด้วย 31.3) ถ้ามีใบรับรอง 1,000 ใบ จะเป็นการต่ออายุประมาณ 900 ครั้งต่อปีที่อายุ 398 วัน ประมาณ 1,800 ครั้งที่ 200 วัน ประมาณ 7,800 ครั้งที่ 47 วัน และใกล้ 11,600 ครั้งถ้าต่ออายุที่สองในสามของอายุ ตัวเลขนี้เป็นการคำนวณของเราเอง ไม่ใช่ประมาณการจากแหล่งอื่น อีกเรื่องที่ต้องรู้คือ เมื่อผลการพิสูจน์โดเมนใช้ซ้ำได้เพียง 10 วัน เกือบทุกครั้งที่ขอใบรับรองต้องพิสูจน์ความเป็นเจ้าของโดเมนใหม่ ซึ่งทำด้วยมือไม่ไหว

วงจรชีวิตของใบรับรอง

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

อะไรควรทำให้อัตโนมัติ และทำอย่างไร

• ACME สำหรับใบรับรองสาธารณะ: ACME (RFC 8555) คือมาตรฐานที่ให้ซอฟต์แวร์ขอ พิสูจน์โดเมน และต่ออายุใบรับรองได้เอง โดยไม่ต้องมีคนทำ เป็นวิธีหลักในการทำใบรับรองสาธารณะให้อัตโนมัติ
• ARI (RFC 9773): ส่วนเสริมของ ACME ที่ให้ CA บอกซอฟต์แวร์ว่าควรต่ออายุตอนไหน ช่วยไม่ให้ทุกระบบมาต่ออายุพร้อมกัน
• เวลาต่ออายุ: Let's Encrypt ระบุว่าถ้าตั้งให้ต่ออายุทุก 60 วันแบบตายตัว จะไม่ทันเมื่อใบรับรองอายุ 45 วัน เพราะใบรับรองหมดอายุก่อนถึงรอบต่อ และการต่ออายุเมื่อผ่านไปประมาณสองในสามของอายุถือว่าใช้ได้ (45 วันคืออายุที่ Let's Encrypt วางแผนใช้ ส่วน 47 วันเป็นอายุสูงสุดตามกติกาของ Forum)
• การพิสูจน์โดเมน: DNS คือระบบที่เชื่อมชื่อโดเมนกับเครื่องที่ให้บริการ และวิธีหนึ่งในการพิสูจน์ว่าควบคุมโดเมนคือการตั้งระเบียน DNS (ค่าที่ตั้งไว้ใน DNS) Let's Encrypt แจ้งเมื่อเดือนธันวาคม 2025 ว่ากำลังมีวิธีพิสูจน์แบบใหม่ผ่าน DNS (DNS-PERSIST-01) ที่ตั้งระเบียน DNS ครั้งเดียวแล้วใช้ต่อได้ และคาดว่าจะพร้อมใช้ในปี 2026 (ตามประกาศตอนนั้น) ควรตรวจสถานะล่าสุดก่อนใช้
• Kubernetes และคลาวด์: เครื่องมืออย่าง cert-manager และบริการใบรับรองของผู้ให้บริการคลาวด์ จะดูแลการต่ออายุภายในคลัสเตอร์และตัวกระจายโหลด (load balancer)
• อุปกรณ์ที่ใช้ CA ภายใน: โปรโตคอลอย่าง EST (RFC 7030) ให้อุปกรณ์ขอใบรับรองเองได้
• การเฝ้าดู: ตั้งการแจ้งเตือนเมื่อใบรับรองไม่ถูกต่ออายุตรงเวลา อย่าพึ่งให้มีคนสังเกตเอง

จุดที่ระบบอัตโนมัติมักติดขัด

• ตัวกระจายโหลดและอุปกรณ์เฉพาะทาง: อุปกรณ์รุ่นเก่าอาจไม่รองรับ ACME ต้องใช้ตัวเชื่อมจากผู้ผลิต หรือวางพร็อกซีไว้ด้านหน้า
• อุปกรณ์ IoT (อุปกรณ์เชื่อมต่อเครือข่าย) และ OT (ระบบควบคุมการผลิต): แก้ไขซอฟต์แวร์ในอุปกรณ์ได้จำกัด เข้าถึงยาก และมักใช้งานกันมานาน จึงต่ออายุยาก
• บริการ SaaS (ซอฟต์แวร์บนคลาวด์) ที่ใช้ชื่อโดเมนของเรา: ผู้ให้บริการอาจเป็นฝ่ายขอและต่ออายุใบรับรองให้เอง เราต้องรู้ว่าใครเป็นคนต่ออายุ
• ใบรับรองที่ถูกตรึง (pinning): แอปบางตัวฝังใบรับรองหรือกุญแจไว้ในโปรแกรม เพื่อใช้เทียบว่าปลายทางที่เชื่อมต่อเป็นของจริง เมื่อใบรับรองเปลี่ยน แอปจะเชื่อมต่อไม่ได้
• สิทธิ์แก้ DNS อยู่กับอีกทีม: การพิสูจน์โดเมนจะค้าง ถ้าทีมที่ดูแล DNS ไม่ได้อยู่ในกระบวนการ
• ใบรับรองใบเดียวใช้กับหลายเซิร์ฟเวอร์: การต่ออายุครั้งเดียวต้องกระจายไปทุกเครื่องให้ครบพร้อมกัน

จัดระบบ: เจ้าของและนโยบาย

• ทะเบียนใบรับรองกลาง: รวบรวมจากหลายแหล่ง เช่น การสแกนเครือข่าย บันทึกสาธารณะ Certificate Transparency (ที่ CA ต้องลงรายการใบรับรองทุกใบที่ออก) ตัวกระจายโหลดบนคลาวด์ และบัญชีผู้ใช้ที่เราเปิดไว้กับ CA
• นโยบาย: กำหนดว่าใช้ CA รายใดได้ ชนิดและขนาดกุญแจ อายุสูงสุด กฎการตั้งชื่อ และใครอนุมัติข้อยกเว้นได้
• ปกป้องกุญแจ: เก็บกุญแจส่วนตัวในระบบจัดการความลับ (secrets manager) หรืออุปกรณ์ฮาร์ดแวร์ ไม่เก็บในโฟลเดอร์ที่ทุกคนเข้าถึงได้
• เกณฑ์แจ้งเตือน: ตั้งตามสัดส่วนของอายุใบรับรอง แทนการตั้งเป็นจำนวนวันตายตัว เพราะถ้าตั้งเตือนล่วงหน้า 30 วัน ใบรับรองอายุ 47 วันจะเริ่มเตือนตั้งแต่ผ่านไปเพียง 17 วันหลังออก ซึ่งเร็วเกินไป
• เชื่อมกับเรื่องตัวตน: ใบรับรองคือตัวตนของเครื่องหรือบริการ ควรจัดการร่วมกับตัวตนที่ไม่ใช่มนุษย์อื่น ๆ (non-human identity) ดู Service Account และ Non-human Identity: ความเสี่ยงที่ถูกมองข้าม
• ความสามารถในการเปลี่ยนวิธีเข้ารหัส (crypto agility): ถ้าระบบเปลี่ยนใบรับรองเองอัตโนมัติอยู่แล้ว ก็จะเปลี่ยนไปใช้วิธีเข้ารหัสใหม่ในอนาคตได้ ดู PQC ความเสี่ยงและวิธีการรับมือ

NIST SP 1800-16 เรื่อง Securing Web Transactions: TLS Server Certificate Management (มิถุนายน 2020) เป็นคู่มือแนวปฏิบัติสำหรับโปรแกรมจัดการใบรับรองของเว็บเซิร์ฟเวอร์ พร้อมตัวอย่างระบบอัตโนมัติที่แสดงวิธีป้องกัน ตรวจพบ และกู้คืนจากเหตุการณ์ที่เกี่ยวกับใบรับรอง แม้เขียนก่อนตารางเวลานี้ ก็ยังใช้เป็นแนวทางได้

ขั้นแรกที่ทำได้ทันที

• ค้นหาใบรับรองสาธารณะของเรา: ค้นบันทึก Certificate Transparency ตามชื่อโดเมน แล้วเทียบกับรายการที่เรามีอยู่
• ทำเครื่องหมายใบที่ยังต่ออายุด้วยมือ: ระบุว่าใบใดวันนี้ยังต้องใช้คนต่ออายุ
• เลือกวิธีอัตโนมัติให้แต่ละประเภท: ACME สำหรับเว็บเซิร์ฟเวอร์และคลาวด์ ตัวเชื่อมสำหรับอุปกรณ์เฉพาะทาง และแผนแยกสำหรับอุปกรณ์อื่น
• ทดสอบในระบบทดลอง (ที่ไม่ใช่ระบบที่ใช้งานจริง) ด้วยใบรับรองอายุสั้น Let's Encrypt มีให้เลือกทั้งโปรไฟล์ที่ออกใบรับรองอายุ 45 วัน และอายุ 6 วัน
• ตั้งการเฝ้าดูและคู่มือเมื่อต่ออายุล้มเหลว: ใครถูกแจ้ง และวิธีสำรองด้วยมือคืออะไร
• ซ้อมกรณีต่ออายุล้มเหลว ดู Network & Cyber Security Simulator: ประเภทและการใช้งาน

หากต้องการทราบว่าการจัดการใบรับรองเข้ากับการควบคุมตัวตนและการเข้ารหัสขององค์กรอย่างไร ลองใช้ แบบประเมินตนเอง

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

• ใช้ปฏิทินเตือนให้คนต่ออายุด้วยมือ: ทำไม่ไหวเมื่อต้องเปลี่ยนใบรับรองทุกไม่กี่สัปดาห์
• ไม่มีเจ้าของ: ไม่มีใครรับผิดชอบเมื่อใบรับรองหมดอายุ โดยเฉพาะหลังมีคนย้ายงาน
• ตั้งรอบต่ออายุแบบตายตัว: สคริปต์ที่ต่ออายุทุก 60 วันจะพังเมื่อใบรับรองอายุ 45 วัน
• มองข้ามใบรับรองที่ไม่ใช่เว็บ: ใบรับรองของ VPN อีเมล อุปกรณ์ และบริการภายในก็หมดอายุเหมือนกัน
• เข้าใจว่า CA ของเราจะลดอายุตามวันที่ของ Forum เท่านั้น: CA อาจลดอายุก่อนวันที่นั้น
• ใช้ wildcard กับทุกระบบ: wildcard คือใบรับรองใบเดียวที่ครอบคลุมทุกชื่อย่อยของโดเมน ถ้ากุญแจถูกขโมยจะกระทบหลายเว็บ และทำให้ไม่รู้ว่าใครเป็นเจ้าของอะไร

ขอบเขตและความถูกต้อง

วันที่ต่าง ๆ มาจากข้อกำหนดพื้นฐานของ CA/Browser Forum (ส่วน Relevant Dates ตามที่อ่านเมื่อ 21 ตุลาคม 2026) และหน้ามติ SC-081v3 ส่วนวันที่ของ Let's Encrypt มาจากประกาศเดือนธันวาคม 2025 ก่อนวางแผน ควรยืนยันค่าปัจจุบันกับ CA และข้อกำหนดฉบับล่าสุดอีกครั้ง เพราะกติกาและตารางเวลาของ CA เปลี่ยนได้

กุญแจ DKIM ก็ต้องมีเจ้าของและแผนเปลี่ยน เหมือนใบรับรอง ดูตัวอย่างการจัดการกุญแจอีเมลใน DMARC, SPF และ DKIM: ตั้งค่าอย่างไรให้ถูกต้อง

กุญแจส่วนตัวของใบรับรองก็เป็นกุญแจเข้ารหัสที่ต้องมีเจ้าของและแผนเปลี่ยน ดู การเข้ารหัสและ Key Management: KMS, HSM และ BYOK

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• CA/Browser Forum Baseline Requirements: ตารางเวลาในหัวข้อ Relevant Dates ข้อ 4.2.1 และ 6.3.2
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods: ผลการลงคะแนนและเหตุผลที่ระบุ
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days: วันที่ดำเนินการและคำแนะนำสำหรับผู้ใช้
• Let's Encrypt: Certificate Lifetime Rationale and Plans
• RFC 8555: ACME
• RFC 9773: ACME Renewal Information (ARI) Extension
• RFC 7030: Enrollment over Secure Transport (EST)
• cert-manager: ระบบจัดการใบรับรองอัตโนมัติสำหรับ Kubernetes
• NIST SP 1800-16: TLS Server Certificate Management