证书有效期缩短到 45 天，一次典型的过期事故该怎么复盘和预防

不少 TLS 故障的复盘结论都一样：证书过期了，而且没人提前发现。症状很典型——浏览器提示证书不受信任、API 客户端报握手失败、CDN 回源异常，但服务器本身运行正常。根因也几乎相同：续期靠人记、靠日历提醒，或者自动化脚本悄悄失败了几周无人巡检。

这类事故的排查路径并不复杂。先用 openssl s_client 或浏览器查看证书 notAfter 时间，确认是过期问题；再查续期任务的日志，看 ACME 续期失败还是根本没跑；最后确认新证书是否部署到了所有入口——很多时候证书续好了，但只更新了一台机器或漏掉了负载均衡层。

值得注意的背景是，留给你发现问题的窗口正在变短。Let's Encrypt 已宣布将证书有效期缩短至 45 天，并相应调整了速率限制，还推出了有效期仅 6 天的短期证书（已在 Certbot 中可用）。人工续期在这种节奏下基本不可行，自动化从"最佳实践"变成了硬性要求。

为了让自动化续期更可靠，Let's Encrypt 推出了 ACME Renewal Information（ARI）：服务器会告诉客户端建议的续期时间窗口，客户端按窗口续期，而不是各自猜测固定间隔。这既能平滑签发高峰，也能在证书需要提前更换时（比如大规模吊销）及时通知客户端。排查续期问题时，值得确认你的 ACME 客户端是否支持并正确处理 ARI。

在 CertbotX 中实践：这类过期事故的自动化防线，CertbotX 已覆盖主要环节。它通过 ACME 协议自动签发并在到期前重新签发证书，签发后可自动部署到 Agent、EdgeOne 或 CDN，部署记录留存可审计——复盘时能直接查到哪台机器、哪个时间点换了哪张证书。如果证书签发在别的账号或受限 DNS 下，也可以用 DNS-01 的 CNAME 委托把验证域名指向 CertbotX 管理的区域，绕开对主域名 DNS 的直接修改。

预防建议收敛为三点：续期和部署全自动化，不留人工环节；监控证书剩余有效期，设置多级告警（比如 14 天、7 天、1 天）；定期演练故障场景。Let's Encrypt 自己也提到"确保你的网站确实是坏的"并不容易——测试环境要能真实暴露证书问题，而不是被缓存或宽松的客户端掩盖。

• Let's Encrypt：缩短证书有效期与速率限制调整
• Let's Encrypt：用 ARI 简化数百万域名的证书续期
• ACME 协议规范 RFC 8555

参考来源

• Let's Encrypt（2026-06-03）：A Post-Quantum Future for Let's Encrypt

https://letsencrypt.org/2026/06/03/pq-certs.html

• Let's Encrypt（2026-04-10）：The difficulty of making sure your website is broken

https://letsencrypt.org/2026/04/10/test-sites.html

• Let's Encrypt（2026-03-17）：Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information (ARI)

https://letsencrypt.org/2026/03/17/acme-renewal-information-ari.html

• Let's Encrypt（2026-03-11）：Six-Day and IP Address Certificates Available in Certbot

https://letsencrypt.org/2026/03/11/shorter-certs-certbot.html

• Let's Encrypt（2026-02-24）：Shorter Certificate Lifetimes and Rate Limits

https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs.html

• Let's Encrypt（2026-02-18）：DNS-PERSIST-01: A New Model for DNS-based Challenge Validation

https://letsencrypt.org/2026/02/18/dns-persist-01.html