บทความ TLS จบหัวข้อการเพิกถอนไว้ว่ามันคือ "ส่วนที่ยัง ไม่เรียบร้อย" — ใบรับรองที่ถูกขโมยกุญแจไปแล้วยังใช้ได้ต่อ เพราะกลไกที่ควร จะบอกว่า "ใบนี้ใช้ไม่ได้แล้ว" ไปไม่ถึงเบราว์เซอร์ทันเวลา หรือไปถึงแล้ว เบราว์เซอร์ก็เลือกที่จะไม่สนใจ
บทความนี้คือสิ่งที่วงการทำกับปัญหานั้น และคำตอบไม่ใช่การซ่อมการเพิกถอน
คำตอบคือ ทำให้ใบรับรองหมดอายุเร็วจนไม่ต้องเพิกถอน
เรื่องนี้มักถูกเล่าผิดสองแบบ แบบแรกคือ "CA อยากขายบ่อยขึ้น" ซึ่งขัดกับผลโหวต ที่จะเห็นข้างล่าง — ฝั่ง CA เป็นฝ่ายคัดค้านมาตลอด แบบที่สองคือคิดว่าเป็น เรื่องของปี 2029 ซึ่งไม่จริง ขั้นแรกมีผลไปแล้วตั้งแต่ 15 มีนาคม 2026 และวัดเห็นได้จากเว็บที่คุณเปิดอยู่ทุกวัน
ถ้ายังไม่เคยดู เริ่มตรงนี้
คำสั่งเดียว ดูว่าใบรับรองของเว็บหนึ่งมีอายุกี่วัน
$ echo | openssl s_client -servername example.com \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -datesได้สองบรรทัด
notBefore=Aug 29 01:40:33 2026 GMT
notAfter=Nov 27 02:40:27 2026 GMTระยะระหว่างสองค่านี้คือสิ่งที่มาตรฐานเรียกว่า validity period และ Baseline Requirements นิยามมันโดยอ้าง RFC 5280 ตรง ๆ ว่า "The period of time from notBefore through notAfter, inclusive."
ตัวอย่างข้างบนคือใบรับรองของเว็บนี้เอง ห่างกัน 90 วัน
เส้นแบ่งที่วัดได้จริงวันนี้
กฎที่บังคับอยู่ตอนนี้อยู่ใน Baseline Requirements ข้อ 6.3.2 และเขียนเป็น ช่วงเวลาไว้ชัดเจน
issued on/after issued before เพดาน
.. 2026-03-15 398 วัน
2026-03-15 2027-03-15 200 วัน
2027-03-15 2029-03-15 100 วัน
2029-03-15 .. 47 วันสังเกตว่ากฎผูกกับ วันที่ออกใบ ไม่ใช่วันที่ใช้งาน ใบที่ออกก่อนเส้นแบ่ง ยังอยู่ครบอายุของมัน
เพราะแบบนั้นวันนี้จึงวัดเห็นสองยุคพร้อมกันบนอินเทอร์เน็ตเดียวกัน
วัดเมื่อ 31 สิงหาคม 2026 ด้วยคำสั่งข้างบน
host issued days issuer
www.thaigov.go.th 2026-03-06 396 GlobalSign
chula.ac.th 2026-01-05 396 Sectigo
krungsri.com 2025-08-21 393 DigiCert
netflix.com 2026-02-18 365 DigiCert
www.microsoft.com 2026-01-23 360 Microsoft
---------------------- เส้นแบ่ง 2026-03-15 -------------
scb.co.th 2026-04-23 199 GlobalSign
www.kasikornbank.com 2026-04-20 198 DigiCert
www.bot.or.th 2026-04-21 198 DigiCert
amazon.com 2026-05-05 197 DigiCert
www.apple.com 2026-07-03 166 Apple
github.com 2026-07-03 89 Sectigo
wikipedia.org 2026-08-06 89 Let's Encrypt
netkubelab.com 2026-08-29 90 Google Trustครึ่งบนออกก่อนเส้นแบ่ง จึงยังยาวใกล้ 398 ครึ่งล่างออกหลังเส้นแบ่ง และ ไม่มีใบไหนแตะ 200 เลย — ธนาคารสามแห่งไปหยุดที่ 198 กับ 199 ซึ่งเป็น ลายเซ็นของระบบที่ขอใบยาวที่สุดเท่าที่กฎอนุญาต
www.thaigov.go.th เป็นตัวอย่างที่ชัดที่สุดของการผูกกฎกับวันออกใบ มันออก วันที่ 6 มีนาคม 2026 — ก่อนเส้นแบ่งเก้าวัน — จึงได้ 396 วัน และจะอยู่ ไปถึงเมษายน 2027 ข้ามยุค 200 วันไปทั้งยุค
แปดปีของการต่อรอง
เพดานนี้ไม่ได้ลดลงเพราะใครค้นพบอะไรใหม่ มันลดลงเพราะการเมืองในห้องประชุม ที่ชื่อ CA/Browser Forum ซึ่งมีสมาชิกสองฝั่ง — Certificate Issuer คือ CA ที่ออกใบ และ Certificate Consumer คือคนทำเบราว์เซอร์กับระบบปฏิบัติการ ที่ตัดสินใจว่าจะเชื่อใบของใคร
กฎข้อบังคับกำหนดว่าจะผ่านต้องได้เสียง สองในสามของฝั่ง CA และ เกินครึ่งของฝั่งเบราว์เซอร์
2017-03-17 Ballot 193 · เพดาน 825 วัน
CA 24 yes 0 no 3 abstain
browser 5 yes 0 no 1 abstain
ผ่าน มีผล 2018-03-01
2019-09-10 Ballot SC22v2 · เพดานราวหนึ่งปี
CA 11 yes 20 no 2 abstain
browser 7 yes 0 no 0 abstain
ตกสองปีห่างกัน เสียงพลิกจากเอกฉันท์เป็นคัดค้านสองต่อหนึ่ง หน้าผลโหวตของ ฟอรัมเองสรุปไว้ว่า "35% of voting Certificate Issuers voted in favor" และ "100% of voting Certificate Consumers voted in favor"
วันที่ฟอรัมตัดสินใจไม่ได้ แล้วมีคนตัดสินใจแทน
หลัง SC22 ตก เรื่องควรจะจบ แต่เดือนกุมภาพันธ์ 2020 Apple ประกาศบนหน้า สนับสนุนของตัวเองว่า
"TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days."
และบรรทัดถัดมาไม่ได้ขออะไรจากใคร
"Connections to TLS servers violating these new requirements will fail."
ไม่มีการโหวต ไม่มีมติ มีแต่การแก้ข้อกำหนดของ root program ตัวเอง และเพราะ ไม่มี CA รายไหนอยากขายใบที่ Safari ไม่ยอมรับ ทั้งวงการจึงย้ายไป 398 วัน ภายในปีเดียว — ตัวเลขเดียวกับที่ CA เพิ่งโหวตคว่ำไปเมื่อห้าเดือนก่อน
รายละเอียดที่บอกอะไรได้มาก คือประโยคนิยามในประกาศของ Apple วันนั้น
"398 days is measured with a day being equal to 86,400 seconds. Any time greater than this indicates an additional day of validity."
ประโยคนั้นแทบไม่ต่างจากข้อความที่อยู่ใน Baseline Requirements ทุกวันนี้ ข้อกำหนดของบริษัทเดียวกลายเป็นมาตรฐานของทั้งวงการ
นี่คือบทเรียนที่ทำให้ผลโหวตปี 2025 ต่างออกไป เมื่อ Ballot SC-081v3 เข้าที่ประชุมเดือนเมษายน 2025 พร้อมกำหนดการลดถึง 47 วัน ผลออกมาว่า
2025-04-11 Ballot SC-081v3 · กำหนดการลดถึง 47 วัน
CA 25 yes 0 no 5 abstain
browser 4 yes 0 no 0 abstain
ผ่าน เข้า BR รุ่น 2.1.5 มีผล 2025-05-16CA กลุ่มเดียวกับที่คว่ำเพดานหนึ่งปีเมื่อหกปีก่อน ไม่มีใครคัดค้านเพดาน 47 วันเลยสักเสียง ห้ารายเลือกงดออกเสียง
การอ่านผลนี้ว่า "CA เปลี่ยนใจแล้ว" น่าจะพลาดประเด็น สิ่งที่เปลี่ยนคือ ทุกคนได้เห็นแล้วว่าทางเลือกอีกทางคือถูกสั่ง ไม่ใช่ถูกถาม
เหตุผลจากตัวบัลลอตเอง
ตัวบัลลอต SC-081v3 เขียนเหตุผลไว้เอง และข้อที่ตรงกับบทความ TLS ที่สุดคือ ข้อนี้
"Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies."
แปลเป็นภาษาคนคือ การเพิกถอนไม่ทำงาน และเราเลิกพยายามทำให้มันทำงานแล้ว
ข้อถัดมาคือเหตุผลเชิงหลักการที่ผมคิดว่าเขียนได้ดีที่สุดในเอกสารทั้งฉบับ
"Certificates are representations of a point in time state of reality. ... The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality."
ใบรับรองไม่ได้พูดถึงปัจจุบัน มันพูดถึงวินาทีที่มันถูกออก ทุกวันที่ผ่านไป คือโอกาสที่ความจริงในใบกับความจริงข้างนอกจะแยกจากกัน — โดเมนหมดอายุแล้วมีคน อื่นจดต่อ กุญแจถูกคัดลอกออกไป บริษัทขายธุรกิจ พนักงานที่ถือกุญแจลาออก บัลลอตอ้างงานวิจัยว่านี่คือ "security-relevant events that enable a third-party to impersonate a domain outside their control"
และข้อที่แหลมที่สุดคือข้อที่ชี้ว่าเรื่องนี้ไม่ใช่ข้อเรียกร้องใหม่เลย
"The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period."
Baseline Requirements บังคับมาตั้งแต่ฉบับแรกว่า CA ต้องเพิกถอนใบภายใน 24 ชั่วโมงในบางกรณี ซึ่งแปลว่ามาตรฐานสมมติมาตลอดว่าเจ้าของเว็บเปลี่ยน ใบรับรองได้ภายในหนึ่งวัน แต่ในความเป็นจริงไม่มีใครทำได้ บัลลอตเขียนต่อว่า "the reality of certificate management practices ... has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs."
47 วันจึงไม่ใช่การเพิ่มข้อเรียกร้อง แต่เป็นการบังคับข้อเรียกร้องที่มี อยู่แล้วให้เป็นจริง ถ้าคุณเปลี่ยนใบไม่ได้ภายใน 47 วัน แปลว่าคุณเปลี่ยน ไม่ได้ภายใน 24 ชั่วโมงอยู่แล้ว และแปลว่าคุณผิดกฎมาตลอดโดยไม่มีใครจับได้
ทำไมเป็น 47
ตัวเลข 47 ดูสุ่มจนคนถามกันมาก และคำตอบที่วนอยู่ในวงการคือ
31 เดือนที่ยาวที่สุด
15 ครึ่งหนึ่งของเดือน 30 วัน
1 เผื่อไว้
--
47เหตุผลเชิงปฏิบัติคือ ต่อใบเดือนละครั้ง ถ้าพลาดหนึ่งรอบยังมีเวลาอีกครึ่ง เดือนให้แก้ตัวก่อนใบตาย
สิ่งที่ต้องบอกให้ตรง — ผมหาที่มาของเลขชุดนี้ในตัวบัลลอต SC-081v3 ไม่เจอ เอกสารบอกแต่ตารางกำหนดการ ไม่ได้อธิบายเลขคณิต คำอธิบาย 31+15+1 มาจาก บล็อกของ CA ที่ร่วมอยู่ในกระบวนการอย่าง DigiCert และ Sectigo ซึ่งเป็น แหล่งทุติยภูมิ ถ้าต้องอ้างในงานจริงให้อ้างแบบนั้น
ตัวเลขที่คนมองข้าม
พาดหัวทุกอันพูดถึง 47 วัน แต่บัลลอตชื่อเต็มว่า "Introduce Schedule of Reducing Validity and Data Reuse Periods" และครึ่งหลังนั่นแหละที่จะ เปลี่ยนงานจริงมากกว่า
Baseline Requirements ข้อ 4.2.1 คุมว่า CA เอาผลการตรวจสอบว่าคุณคุมโดเมน จริงมาใช้ซ้ำได้นานแค่ไหน ตารางนั้นลดลงเร็วกว่าตารางอายุใบ
issued on/after issued before ใช้ผลตรวจโดเมนซ้ำได้
.. 2026-03-15 398 วัน
2026-03-15 2027-03-15 200 วัน
2027-03-15 2029-03-15 100 วัน
2029-03-15 .. 10 วันบรรทัดสุดท้ายไม่ใช่ 47 แต่เป็น 10
แปลว่าตั้งแต่มีนาคม 2029 ใบรับรองหนึ่งใบอยู่ได้ 47 วัน แต่หลักฐานว่าคุณ เป็นเจ้าของโดเมนอายุแค่ 10 วัน คุณจึงต้องพิสูจน์การควบคุมโดเมนใหม่ บ่อยกว่าที่คุณต่อใบรับรองเสียอีก
ถ้าองค์กรของคุณยังใช้วิธีตรวจแบบวางไฟล์ในเว็บหรือแก้ระเบียน DNS ด้วยมือ นี่คือบรรทัดที่จะทำให้วิธีนั้นตาย ไม่ใช่บรรทัด 47 วัน
อีกตารางหนึ่งลดพร้อมกันเงียบ ๆ คือข้อมูลตัวตนขององค์กรสำหรับใบชนิด OV กับ EV ซึ่งเดิมใช้ซ้ำได้ 825 วัน เหลือ 398 วันตั้งแต่ 15 มีนาคม 2026
ใบอายุสั้น และการยกเว้นที่มากับมัน
มาตรฐานมีประเภทพิเศษชื่อ Short-lived Subscriber Certificate และนิยาม ของมันก็เพิ่งเข้มขึ้นในวันเดียวกับที่เพดานลงมา 200
2024-03-15 .. 2026-03-15 ไม่เกิน 10 วัน (864,000 วินาที)
2026-03-15 .. ไม่เกิน 7 วัน (604,800 วินาที)สิ่งที่ได้มาคือการยกเว้นที่เขียนไว้ตรง ๆ ในข้อ 4.9.1.1
"The CA MAY support revocation of Short-lived Subscriber Certificates."
MAY ไม่ใช่ SHALL — ใบอายุสั้น ไม่จำเป็นต้องเพิกถอนได้ด้วยซ้ำ และ ไม่ต้องปรากฏใน CRL ส่วนใบธรรมดาผูกอยู่กับประโยคที่ขึ้นต้นว่า "With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours"
ตรรกะตรงไปตรงมา ถ้าใบตายใน 7 วันอยู่แล้ว การประกาศว่ามันใช้ไม่ได้ก็ไม่ทัน มีประโยชน์ อายุคือกลไกเพิกถอน
และนี่ไม่ใช่ทฤษฎี วัดวันเดียวกันกับตารางข้างบน
$ echo | openssl s_client -servername www.dga.or.th \
-connect www.dga.or.th:443 2>/dev/null \
| openssl x509 -noout -issuer -dates
issuer= /C=US/O=Google Trust Services/CN=WE1
notBefore=Aug 21 15:02:39 2026 GMT
notAfter=Sep 4 16:02:35 2026 GMTหน่วยงานรัฐไทยแห่งหนึ่งใช้ใบอายุ 14 วัน อยู่ตอนนี้ ผู้ออกรายเดียวกับ เว็บนี้ และนโยบายเดียวกัน (OID 2.23.140.1.2.1 คือ domain validated) ต่างกันแค่ตัวเลือกของเจ้าของเว็บ
ฝั่งผู้ให้บริการก็เปิดทางไว้แล้ว Let's Encrypt ประกาศโปรไฟล์ไว้สามแบบ
classic 90 days ค่าตั้งต้น
tlsserver 45 days
shortlived 160 hours "6ish days" ตามที่เอกสารเขียนเอง160 ชั่วโมงเท่ากับ 576,000 วินาที ซึ่งต่ำกว่าเพดาน 604,800 วินาที จึงเข้า นิยามใบอายุสั้นแบบใหม่พอดี ส่วน tlsserver ที่ 45 วันคือการซ้อมอยู่ใต้ เพดาน 47 ล่วงหน้าสามปี
วันหนึ่งคือ 86,400 วินาที
รายละเอียดที่อธิบายว่าทำไมไม่มีใครออกใบ 200 วันเป๊ะ อยู่ท้ายข้อ 6.3.2
"For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments."
วินาทีเดียวเกินคือหนึ่งวันเต็ม มาตรฐานเลยเขียนเพดานเป็นคู่ทุกชั้น
SHOULD NOT MUST NOT
.. .. 2026-03-15 397 398
2026-03-15 .. 2027-03-15 199 200
2027-03-15 .. 2029-03-15 99 100
2029-03-15 .. 46 47ตัวเลขซ้ายคือเป้าที่ควรออก ตัวเลขขวาคือเส้นที่ห้ามข้าม CA ที่ออก 200 วัน เป๊ะแล้วนาฬิกาคลาดไปหนึ่งวินาที จะกลายเป็นออกใบผิดกฎทันที ซึ่งนำไปสู่การ เพิกถอนหมู่และรายงานเหตุการณ์ต่อ root program
เมื่อกลับไปดูตารางที่วัดได้ตอนต้น ตัวเลข 197 198 199 จึงไม่ใช่ความบังเอิญ แต่คือระยะเผื่อที่แต่ละ CA เลือกไว้ต่างกัน และไม่มีใครกล้าแตะ 200
สิ่งที่ต้องเปลี่ยนในงานจริง
ถ้ายังต่อใบด้วยมืออยู่ ตัวเลขที่ควรดูคือจำนวนครั้งต่อปี
สี่คอลัมน์คือ อายุใบเป็นวัน · จำนวนครั้งที่ต้องต่อต่อปี · หน้าต่างที่เหลือ ให้รู้ตัวและแก้ทันถ้าต่อเมื่อเหลืออายุหนึ่งในสาม · และสิ่งที่มันแปลว่าอะไร
398 ~1 /yr 133 d กว้างมาก
200 ~2 /yr 67 d ยังไหว
100 ~4 /yr 33 d เริ่มตึง
47 ~8 /yr 16 d ต้องอัตโนมัติที่ 47 วัน หน้าต่างสำหรับสังเกตว่าการต่อใบล้มเหลวแล้วแก้ทัน เหลือราวสอง สัปดาห์ และเกิดขึ้นแปดครั้งต่อปีต่อใบหนึ่งใบ องค์กรที่มี 300 โดเมนจะได้ งานต่อใบ 2,400 ครั้งต่อปี — ไม่มีทางทำด้วยคน
โพรโทคอลที่รองรับเรื่องนี้คือ ACME ตาม RFC 8555 ซึ่งออกเดือนมีนาคม 2019 โดยมีคนจาก Let's Encrypt, EFF และ Cisco ร่วมเขียน มันทำให้การขอและต่อใบเป็นการเรียก API แทนการกรอกฟอร์ม
ปัญหาที่ตามมาเมื่อทุกคนต่อใบอัตโนมัติคือทุกคนต่อพร้อมกัน RFC 9773 เดือนมิถุนายน 2025 เพิ่มส่วนขยายชื่อ ACME Renewal Information (ARI) ให้เซิร์ฟเวอร์บอกลูกค้าได้ว่าควรมาต่อเมื่อไหร่ บทคัดย่อเขียนเหตุผลไว้ว่า เพื่อ "mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods"
ARI ยังทำอีกอย่างที่สำคัญกว่า — ถ้า CA ต้องเพิกถอนใบหมู่เพราะออกผิดกฎ มันบอกลูกค้าให้รีบมาต่อก่อนกำหนดได้ แทนที่จะส่งอีเมลหาคนหลายหมื่นคน
เมื่อมันโกหก
"ใบยังไม่หมดอายุ แปลว่ายังปลอดภัย" ผิดคนละเรื่อง วันหมดอายุบอกแค่ว่า เมื่อไหร่เบราว์เซอร์จะเลิกรับ ไม่ได้บอกว่ากุญแจยังเป็นความลับอยู่ไหม อายุที่สั้นลงไม่ได้ทำให้ใบปลอดภัยขึ้น มันแค่ทำให้ใบที่ไม่ปลอดภัยแล้ว มีอายุใช้งานสั้นลง
"ลดอายุแล้วปลอดภัยขึ้นทันที" ไม่ใช่ ใบที่ออกก่อน 15 มีนาคม 2026 ยัง เดินอายุเดิมของมันอยู่ ตารางที่วัดได้ข้างบนแสดงใบ 396 วันที่จะอยู่ถึง เมษายน 2027 ผลของกฎจะเต็มที่ก็ต่อเมื่อใบยุคเก่าหมดไปทั้งหมด
"เป็นเรื่องของปี 2029" ไม่ใช่ ขั้น 200 วันบังคับแล้ว และขั้น 100 วัน มีผล 15 มีนาคม 2027 ซึ่งเหลือเวลาไม่ถึงเจ็ดเดือนนับจากวันที่เขียนบทความนี้
"ต่ออัตโนมัติแล้วจบ" ยังไม่จบ การต่อใบสำเร็จไม่ได้แปลว่าบริการโหลดใบ ใหม่แล้ว ระบบจำนวนมากอ่านใบตอนสตาร์ตครั้งเดียว เคสที่เจอบ่อยที่สุดคือ ACME ต่อใบสำเร็จทุกครั้ง ไฟล์บนดิสก์ใหม่เอี่ยม แต่เว็บเซิร์ฟเวอร์ยังเสิร์ฟ ใบเก่าจากหน่วยความจำจนหมดอายุจริง
"ใบอายุสั้นแปลว่าไม่ต้องเฝ้า" กลับกัน ยิ่งสั้นยิ่งต้องเฝ้า เพราะความ ผิดพลาดมีเวลาสะสมน้อยลงก่อนกลายเป็นเว็บล่ม
ตัวอย่างจริงจากงานจริง
กรณีที่ 1 — ตรวจว่าองค์กรตัวเองอยู่ยุคไหน
สถานการณ์ ต้องรู้ว่าโดเมนไหนขององค์กรจะเจอกำแพงก่อน
คำสั่ง
$ for h in a.example.com b.example.com; do
echo | openssl s_client -servername $h -connect $h:443 \
2>/dev/null | openssl x509 -noout -subject -dates
doneเอาต์พุตจริง จากตารางที่วัดไว้ข้างบน ตัดมาสองบรรทัด
www.thaigov.go.th issued 2026-03-06 396 d ends 2027-04-07
scb.co.th issued 2026-04-23 199 d ends 2026-11-08อ่านอย่างไร ใบแรกออกก่อนเส้นแบ่ง จึงยังได้อายุยุคเก่า และตอนต่อใบครั้ง ถัดไปในเมษายน 2027 จะตกไปอยู่ใต้เพดาน 100 วัน ทันที เพราะเลยเส้น 15 มีนาคม 2027 ไปแล้ว — ลดจาก 396 เหลือ 100 ในการต่อครั้งเดียว ใบที่สอง ปรับตัวไปแล้วครึ่งทาง การต่อครั้งหน้ายังอยู่ใต้เพดาน 200
สิ่งที่ยังไม่ได้พิสูจน์ เรารู้แค่ว่าใบใบนี้ถูกออกเมื่อไหร่และยาวเท่าไหร่ ไม่รู้ว่าองค์กรนั้นต่อใบด้วยมือหรืออัตโนมัติ ใบยาวไม่ได้แปลว่าทำมือ และ ใบสั้นไม่ได้แปลว่าอัตโนมัติ ต้องถามคนดูแลเท่านั้น
กรณีที่ 2 — ใบต่อสำเร็จแต่เว็บยังเสิร์ฟใบเก่า
สถานการณ์ ระบบแจ้งเตือนบอกว่าใบใกล้หมดอายุ ทั้งที่ ACME รายงานว่าต่อ สำเร็จเมื่อสัปดาห์ก่อน
คำสั่ง เทียบใบบนดิสก์กับใบที่เสิร์ฟจริง
$ openssl x509 -in /etc/ssl/live/example.com/cert.pem \
-noout -enddate
notAfter=Nov 27 02:40:27 2026 GMT
$ echo | openssl s_client -servername example.com \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -enddate
notAfter=Sep 4 01:15:11 2026 GMTอ่านอย่างไร สองค่าไม่ตรงกันคือคำตอบทั้งหมด ไฟล์ถูกต่ออายุแล้ว แต่ โพรเซสที่ฟังพอร์ต 443 ยังถือใบเก่าที่อ่านตอนสตาร์ตไว้ในหน่วยความจำ ปัญหาไม่ได้อยู่ที่ ACME แต่อยู่ที่ hook หลังต่อใบไม่ได้สั่งให้บริการโหลดใหม่
สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าโพรเซสไหนถืออยู่ ถ้ามีหลายชั้น เช่น reverse proxy หน้าแอป ใบเก่าอาจอยู่ที่ชั้นใดชั้นหนึ่งก็ได้ ต้องไล่ทีละชั้น ด้วยการต่อตรงเข้าแต่ละพอร์ต
กรณีที่ 3 — ดูประวัติการต่อใบจากบันทึกสาธารณะ
สถานการณ์ อยากรู้ว่าเว็บหนึ่งต่อใบถี่แค่ไหนจริง ๆ โดยไม่ต้องเข้าไปดู ในเครื่อง ทุกใบที่ CA ออกต้องถูกบันทึกลง Certificate Transparency
คำสั่ง
$ curl -s "https://crt.sh/?q=netkubelab.com&output=json" \
| python3 -m json.tool | head -40เอาต์พุตจริง ย่อเหลือแก่น เรียงตามวันออก
issued expires days gap
2026-04-20 2026-07-19 90 -
2026-06-18 2026-09-16 89 58 วัน
2026-08-16 2026-11-14 89 58 วัน
2026-08-23 2026-11-21 90 7 วันอ่านอย่างไร สองช่วงแรกห่างกัน 58 วันเท่ากันบนใบอายุ 89 ถึง 90 วัน คือ การต่อเมื่อเหลืออายุราวหนึ่งในสาม ซึ่งเป็นธรรมเนียมของไคลเอนต์ ACME และ เป็นสิ่งที่ ARI เข้ามาทำให้เป็นทางการ ส่วนใบที่ห่างมาเจ็ดวันคือการออกใบ นอกรอบ ไม่ใช่การต่อตามกำหนด
สิ่งที่ยังไม่ได้พิสูจน์ CT บันทึก precertificate กับ certificate เป็น คนละรายการ การนับจำนวนแถวจึงมากกว่าจำนวนครั้งที่ออกจริง และแพลตฟอร์มที่ จัดการใบให้อาจออกใบใหม่ด้วยเหตุอื่นที่ไม่เกี่ยวกับวันหมดอายุ เช่น เพิ่ม ชื่อโดเมนหรือย้ายเครื่อง หลักฐานชุดนี้บอกจังหวะได้ แต่บอกเหตุผลไม่ได้
กรณีที่ 4 — ประเมินว่าจะเจ็บตรงไหนก่อน
สถานการณ์ วางแผนล่วงหน้าก่อนเส้น 15 มีนาคม 2027
คำสั่ง ไล่ทุกโฮสต์แล้วเรียงตามอายุใบจากมากไปน้อย
$ for h in $(cat hosts.txt); do
d=$(echo | openssl s_client -servername $h -connect $h:443 \
2>/dev/null | openssl x509 -noout -enddate)
printf "%-30s %s\n" "$h" "$d"
done | sort -k2อ่านอย่างไร โฮสต์ที่ใบยาวที่สุดคือโฮสต์ที่เจ็บที่สุด ไม่ใช่เพราะใบมัน แย่ แต่เพราะมันคือระบบที่ยังไม่เคยถูกบังคับให้ต่อใบบ่อย จึงมีโอกาสสูงสุด ที่จะไม่มีระบบอัตโนมัติรองรับ ใบ 396 วันที่ต่อครั้งหน้าแล้วเหลือ 100 วัน คือการเพิ่มความถี่เกือบสี่เท่าในคราวเดียว
สิ่งที่ยังไม่ได้พิสูจน์ รายการนี้เห็นเฉพาะโฮสต์ที่รู้จักและเปิดพอร์ต 443 สู่อินเทอร์เน็ต ใบที่อยู่บนอุปกรณ์ภายใน เครื่องทดสอบ หรือบริการที่ คุยกันเองภายในองค์กร ไม่โผล่ในรายการนี้เลย และมักเป็นกลุ่มที่ลืมมากที่สุด
เมื่อเรื่องนี้ยังไม่จบ
กำหนดการหยุดที่ 47 วันในปี 2029 แต่ไม่มีอะไรในเอกสารบอกว่านั่นคือปลายทาง ตารางการใช้ผลตรวจโดเมนซ้ำลงไปถึง 10 วันแล้ว และ Let's Encrypt ก็ออกใบ 160 ชั่วโมงให้ใช้อยู่ตอนนี้
ทิศทางชัดว่าใบรับรองกำลังเปลี่ยนจาก เอกสารที่ถือไว้ เป็น สิ่งที่ระบบ หยิบมาใช้แล้วทิ้ง — ซึ่งเป็นรูปร่างเดียวกับที่ DHCP ทำกับเลขไอพีเมื่อสามสิบปีก่อน คือเลิกคิดว่าใครเป็นเจ้าของ แล้วคิดว่าใคร ยืมอยู่ตอนนี้
อ้างอิง
มาตรฐาน
- CA/Browser Forum Baseline Requirements รุ่น 2.2.9 ลงวันที่ 6 สิงหาคม 2026 — ข้อ 6.3.2 ตารางอายุ ข้อ 4.2.1 ตารางการใช้ผลตรวจซ้ำ และข้อ 4.9.1.1 การยกเว้นของใบอายุสั้น
- RFC 5280 ที่มาของนิยาม validity period ที่ทั้ง Apple และ Baseline Requirements อ้าง
- RFC 8555 ACME มีนาคม 2019
- RFC 9773 ACME Renewal Information มิถุนายน 2025
ผลโหวตและประกาศ
- Ballot 193 เพดาน 825 วัน ผ่านเอกฉันท์ปี 2017
- Ballot SC022v2 ตกในปี 2019 พร้อมรายชื่อผู้ลงคะแนนทุกราย
- Ballot SC-081v3 ที่มาของกำหนดการปัจจุบัน พร้อมเหตุผลที่ยกมาอ้างในบทความนี้
- ประกาศของ Apple เรื่องเพดาน 398 วัน ซึ่งไม่ได้ผ่านการโหวตใด ๆ
คู่มือ
- โปรไฟล์ใบรับรองของ Let's Encrypt ตัวเลข 90 วัน 45 วัน และ 160 ชั่วโมงมาจากหน้านี้