บทความ › ความปลอดภัย

ใบรับรอง SSL/TLS อายุสั้นลงเหลือ 47 วัน: ไทม์ไลน์ 2026-2029 และต้องทำอะไร

CA/B Forum ลดอายุใบรับรอง TLS จาก 398 วันเหลือ 47 วันภายในปี 2029 ส่วน Let's Encrypt มีใบ 6 วันและใบสำหรับ IP แล้ว สรุปไทม์ไลน์ และวิธีตั้งต่ออายุอัตโนมัติ

เริ่มต้น อ่าน 9 นาที 23 ตุลาคม 2569

อ่านจบแล้วจะรู้
  • ตั้งแต่ 15 มีนาคม 2026 ใบรับรองสาธารณะออกได้ไม่เกิน 200 วัน ปี 2027 เหลือ 100 วัน และปี 2029 เหลือ 47 วัน
  • Let's Encrypt จะลดใบปกติจาก 90 เป็น 64 วันในกุมภาพันธ์ 2027 และ 45 วันในกุมภาพันธ์ 2028
  • ใบ 47 วันต้องต่อราวเดือนละครั้ง ต่อด้วยมือไม่ไหว ต้องให้เครื่องต่อเอง แล้วตั้งแจ้งเตือนเมื่อการต่อล้มเหลว
  • Let's Encrypt ออกใบอายุ 160 ชั่วโมง (shortlived) และใบสำหรับ IP address ได้แล้ว ทั้งสองแบบต้องเลือกใช้เอง

ใบรับรอง SSL/TLS ที่ทำให้เว็บขึ้นแม่กุญแจกำลังอายุสั้นลงเป็นขั้น ๆ จาก 398 วันเหลือ 47 วันในปี 2029 ตามมติของ CA/Browser Forum ที่ผ่านเมื่อเมษายน 2025 ขั้นแรกเริ่มไปแล้วเมื่อ 15 มีนาคม 2026 ใครที่ยังต่ออายุด้วยมือปีละครั้ง จะต้องทำถี่ขึ้นเรื่อย ๆ จนทำด้วยมือไม่ไหว บทความนี้สรุปตารางเวลา สิ่งที่ Let’s Encrypt เปลี่ยน และวิธีเช็กว่าเครื่องเราต่ออายุเองจริง

ตรวจข้อเท็จจริงกับ: ประกาศ Ballot SC-081v3 ของ CA/B Forum, บล็อก DigiCert และประกาศของ Let’s Encrypt ณ ตุลาคม 2026 คำสั่งเขียนสำหรับ Ubuntu 24.04 กับ certbot

ทำไมต้องสั้นลง

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

มติผ่านเมื่อ 11 เมษายน 2025 ฝั่งผู้ออกใบ 25 เสียงเห็นด้วย 0 ไม่เห็นด้วย 5 งดออกเสียง ฝั่งเบราว์เซอร์ 4 เสียงเห็นด้วยทั้งหมด

ก่อน มี.ค. 2026อายุสูงสุด 398 วัน15 มี.ค. 2026200 วัน15 มี.ค. 2027100 วัน15 มี.ค. 202947 วัน
เพดานอายุใบรับรองสาธารณะตามมติ SC-081

ไทม์ไลน์ SC-081

มีผลตั้งแต่อายุใบสูงสุดใช้ผลยืนยันโดเมนซ้ำได้นานสุด
ก่อน 15 มี.ค. 2026398 วัน398 วัน
15 มี.ค. 2026200 วัน200 วัน
15 มี.ค. 2027100 วัน100 วัน
15 มี.ค. 202947 วัน10 วัน

คอลัมน์ขวาสำคัญไม่แพ้กัน “ผลยืนยันโดเมน” (domain control validation, DCV) คือการพิสูจน์ว่าเราคุมโดเมนนั้นจริง เช่น วางไฟล์บนเว็บหรือใส่ TXT record ใน DNS ปี 2029 ใช้ผลยืนยันซ้ำได้แค่ 10 วัน แปลว่าเกือบทุกครั้งที่ต่อใบ ต้องยืนยันโดเมนใหม่ด้วย ถ้าขั้นนี้ยังทำด้วยมือ ก็ต้องทำอัตโนมัติเหมือนกัน

ตารางนี้เป็นเพดานของทุก CA สาธารณะ ใบที่ซื้อจาก CA แบบเสียเงินก็โดนเหมือนกัน

Let’s Encrypt เปลี่ยนอะไรบ้าง

Let’s Encrypt ออกใบ 90 วันมานานแล้ว ต่ำกว่าเพดานอยู่แล้ว แต่ก็ประกาศลดต่อ

วันที่profileอายุใบใช้ผลยืนยันซ้ำ
ปัจจุบันclassic (ค่าเริ่มต้น)90 วัน30 วัน
13 พ.ค. 2026tlsserver (เลือกใช้เอง)45 วันไม่ได้ระบุ
10 ก.พ. 2027classic64 วัน10 วัน
16 ก.พ. 2028classic45 วัน7 ชั่วโมง

ฝั่ง staging จะเปลี่ยนก่อน production ราวหนึ่งเดือน และเราจะเห็นใบสั้นลงในรอบต่ออายุแรกหลังแต่ละวันที่

อีกเรื่องที่ใหม่คือ ตั้งแต่ 15 มกราคม 2026 ใบอายุสั้น (profile shortlived) และใบสำหรับ IP address เปิดให้ทุกคนใช้แล้ว

  • ใบ shortlived มีอายุ 160 ชั่วโมง หรือราว 6 วันกว่า ต้องเลือกใช้เอง Let’s Encrypt บอกว่ายังไม่มีแผนทำเป็นค่าเริ่มต้น
  • ใบสำหรับ IP address (ทั้ง IPv4 และ IPv6) ต้องเป็นใบ shortlived เท่านั้น
  • certbot ขอใบ IP ได้ตั้งแต่ 5.3 (webroot ต้อง 5.4 ขึ้นไป) แต่ยังติดตั้งเข้า nginx ให้อัตโนมัติไม่ได้ ต้องชี้ไฟล์ใน /etc/letsencrypt/live/<ip>/ เอง
# ตัวอย่างจาก Let's Encrypt: ขอใบ IP บน staging ก่อน (certbot 5.4+)
sudo certbot certonly --staging \
  --preferred-profile shortlived \
  --webroot --webroot-path /var/www/html \
  --ip-address 192.0.2.10

ตัวอย่างคำนวณ: ต้องต่อกี่ครั้งต่อปี

สมมติดูแลเว็บ 10 โดเมน ต่อด้วยมือครั้งละ 30 นาที (ขอใบ ยืนยันโดเมน ติดตั้ง reload) และใช้กติกาเดียวกันทุกแบบ คือต่อเมื่อใช้ไปราวสองในสามของอายุ (ตัวเลขที่ Let’s Encrypt บอกว่ารับได้)

  1. 398 วัน: ต่อทุก 398 × 2/3 ≈ 265 วัน → 365 ÷ 265 ≈ 1.4 ครั้งต่อปีต่อโดเมน
  2. 200 วัน (ตอนนี้): ต่อทุก ≈ 133 วัน → 365 ÷ 133 ≈ 2.7 ครั้ง
  3. 100 วัน (2027): ต่อทุก ≈ 67 วัน → 365 ÷ 67 ≈ 5.4 ครั้ง
  4. 47 วัน (2029): ต่อทุก ≈ 31 วัน → 365 ÷ 31 ≈ 11.8 ครั้ง หรือราว เดือนละครั้ง

รวม 10 โดเมนตอนใบ 47 วัน: 11.8 × 10 = 118 ครั้งต่อปี × 30 นาที = 59 ชั่วโมงต่อปี เทียบกับตอน 398 วัน: 1.4 × 10 × 0.5 = 7 ชั่วโมง งานเดิมโตขึ้นราว 8 เท่า และแค่ลืมครั้งเดียว เว็บก็ขึ้นหน้าเตือนสีแดง

ใบ 6 วันยิ่งชัด 160 × 2/3 ≈ 107 ชั่วโมง คือต่อทุก 4 วันกว่า ไม่มีทางทำด้วยมือ

อายุใบไม่ใช่ปัญหา การต่อด้วยมือคือปัญหา ถ้าเครื่องต่อเองได้ ใบ 47 วันกับ 398 วันแทบไม่ต่างกันในชีวิตจริง

เช็กว่าเครื่องเราต่อเองจริง

บน Ubuntu ถ้าติดตั้ง certbot ด้วย snap หรือ apt จะมี systemd timer ต่ออายุให้ (ชื่อ snap.certbot.renew.timer หรือ certbot.timer แล้วแต่วิธีติดตั้ง) เช็กสามอย่าง

# 1) มี timer และรันล่าสุดเมื่อไร
systemctl list-timers | grep -i certbot

# 2) ลองต่ออายุจริงกับ staging โดยไม่เปลี่ยนใบ
sudo certbot renew --dry-run

# 3) ใบที่เว็บเสิร์ฟอยู่ หมดอายุวันไหน
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

ข้อ 3 สำคัญกว่าที่คิด ใบในดิสก์ต่อแล้ว ไม่ได้แปลว่าเว็บเสิร์ฟใบใหม่ ถ้า nginx ไม่ได้ reload ใบเก่ายังอยู่ในหน่วยความจำ ให้ certbot reload ให้ทุกครั้งที่ต่อสำเร็จ

# ตั้ง deploy hook ให้ใบที่มีอยู่ (ทำครั้งเดียว ค่าถูกเก็บใน renewal config)
sudo certbot reconfigure --cert-name example.com \
  --deploy-hook "systemctl reload nginx"

แล้วตั้งแจ้งเตือนเมื่อใบเหลือน้อยกว่า 14 วัน ใช้วิธีเดียวกับ บอทเฝ้าเซิร์ฟเวอร์ส่ง Telegram ได้ เอาคำสั่งข้อ 3 ไปคำนวณจำนวนวันที่เหลือ ถ้าเลยเกณฑ์ให้ส่งข้อความ ใบต่ออายุไม่สำเร็จจะเงียบเสมอ จนวันที่มันหมด

งานที่ต้องเตรียมก่อนปี 2029

  • ย้ายการยืนยันโดเมนเป็นอัตโนมัติ ถ้าใช้ DNS-01 ต้องให้เครื่องแก้ TXT record เองผ่าน API ของผู้ให้บริการ DNS Let’s Encrypt บอกว่ากำลังทำวิธีใหม่ชื่อ DNS-PERSIST-01 ร่วมกับ CA/B Forum และ IETF ตั้ง TXT ครั้งเดียวไม่ต้องแก้ทุกรอบ คาดว่าจะมีในปี 2026
  • เลิก cron ที่ต่อทุก 60 วันตายตัว Let’s Encrypt บอกตรง ๆ ว่ารอบแบบนี้จะไม่พอเมื่อใบเหลือ 45 วัน ใช้ client ที่รองรับ ACME Renewal Information (ARI) หรือต่อเมื่อใช้ไปสองในสามของอายุ
  • นับใบที่ติดตั้งด้วยมือ ใบที่ copy ไปวางบน load balancer, อุปกรณ์ network, หรือแอปที่ไม่ได้อ่านจาก /etc/letsencrypt คือจุดที่จะหมดอายุเงียบ ๆ

เมื่อ HTTPS ต่ออายุเองได้แล้ว อย่าลืมตั้ง HSTS และหัวความปลอดภัยอื่น ดูใน security headers บน nginx

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

  • ต่อใบแล้วไม่ reload ใบใหม่อยู่ในดิสก์ แต่เว็บยังเสิร์ฟใบเก่าจนหมดอายุ
  • ทดสอบกับ production ซ้ำ ๆ จนชน rate limit ใช้ --dry-run หรือ --staging ตอนทดลอง
  • ไม่มีใครได้อีเมลเตือน อีเมลที่ลงทะเบียนตอนขอใบเป็นของคนที่ลาออกไปแล้ว ตั้งแจ้งเตือนของเราเองดีกว่า
  • ใบสำหรับ IP แล้วใช้ปลั๊กอิน nginx ณ ตุลาคม 2026 certbot ยังติดตั้งใบ IP ให้ nginx/apache ไม่ได้ ต้องใช้ certonly แล้วตั้ง path เอง
  • ลืมว่า staging เปลี่ยนก่อน ถ้าระบบทดสอบใช้ staging จะเจอใบสั้นลงก่อน production ราวเดือนหนึ่ง เป็นโอกาสดีที่จะเห็นปัญหาก่อน

แหล่งอ้างอิง

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

ใบที่ซื้อไว้ 1 ปีก่อนมีนาคม 2026 ใช้ไม่ได้แล้วหรือ

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

ใช้ Let's Encrypt กับ certbot อยู่แล้ว ต้องทำอะไรเพิ่มไหม

ส่วนใหญ่ไม่ต้อง certbot ตั้ง timer ต่ออายุให้ตอนติดตั้ง และต่อเมื่อเหลืออายุน้อย ให้ทดสอบด้วย certbot renew --dry-run ดูว่ามี timer จริง และ reload เว็บเซิร์ฟเวอร์หลังต่อ ที่ต้องระวังคือ cron ที่เขียนเองแบบต่อทุก 60 วันตายตัว จะไม่พอเมื่อใบเหลือ 45 วัน

ใบ 6 วันเหมาะกับใคร

ระบบที่ต่ออายุอัตโนมัติมั่นคงแล้ว และอยากลดความเสียหายถ้า private key หลุด เพราะใบหมดอายุเองในไม่กี่วัน และเป็นแบบเดียวที่ Let's Encrypt ออกให้ IP address ได้ ถ้าการต่ออายุยังเคยล้ม อย่าเพิ่งใช้

คำสั่งและค่าตั้งในบทความทดสอบบนระบบตัวอย่าง ลองบนเครื่องทดสอบก่อนใช้กับระบบจริงเสมอ

อ่านต่อ

#Securityกลาง

Post-quantum บน SSH และ HTTPS: ML-KEM คืออะไร และเช็กเซิร์ฟเวอร์ของเรายังไง

OpenSSH 10 ใช้ mlkem768x25519 เป็นค่าเริ่มต้นแล้ว 10.1 เตือนเมื่อไม่ได้ใช้ เบราว์เซอร์ก็ใช้ X25519MLKEM768 วิธีเช็กว่าเซิร์ฟเวอร์ตกลงใช้อะไรจริง และต้องอัปเกรดอะไร

อ่าน 8 นาที
#Securityกลาง

กัน CSRF โดยไม่ต้องใช้ token ด้วย Sec-Fetch-Site และ Origin (Go 1.25)

เบราว์เซอร์ยุคนี้บอกเซิร์ฟเวอร์เองว่าคำขอมาจากเว็บอื่นหรือเปล่า เช็กหัว Sec-Fetch-Site กับ Origin แทน CSRF token ได้ วิธีทำใน Go 1.25 และข้อแม้ที่ต้องรู้

อ่าน 10 นาที
#Securityเริ่มต้น

เผลอ push API key ขึ้น Git ทำอะไรก่อน: เปลี่ยนกุญแจ ล้างประวัติ กันซ้ำ

API token หลุดขึ้น GitHub ลบ commit ไม่ช่วย ต้องเปลี่ยนกุญแจก่อน แล้วค่อยตรวจ log ล้างประวัติด้วย git filter-repo และตั้ง gitleaks กับ push protection กันครั้งหน้า

อ่าน 10 นาที