2027 年 2 月 10 日,Let's Encrypt 所有订阅者将默认拿到 64 天有效期的证书——除非你自己选了更短的 45 天或 6 天。这是它 2026 年 10 月 7 日官宣的时间表。同一天它还给全体证书运营者留了句话:『我们不会因为这次变更吊销任何有效证书。』

真正的动作细节在时间线里。2026 年 10 月 14 日,staging 环境先切到 64 天,供实测;2027 年 2 月 10 日生产环境全面生效;预计最后一张 90 天证书在 2027 年 5 月 11 日到期。留给手动运维的过渡窗口,是从现在到明年五月。
如果你的续期完全自动化、且 ACME 客户端支持 ARI(ACME Renewal Info),就什么都不用改——ARI 的意思是 Let's Encrypt 能主动告诉你的客户端『现在该续了』。麻烦的是写死日期的那批人:按『证书到期前固定天数』续期的脚本,要被改写为约 ⅔ 生命周期处续期。官方甚至建议直接 grep 自己的 cron、wrapper 脚本和 runbook 里的 83、80、60 这些写死的数字。这个改动同时是为 2028 年默认 45 天铺路。

另一处被忽略的变更:授权复用期从 30 天砍到 10 天,2028 年还要再缩到七个小时——为了提前合规 2029 年对最大验证复用期的更严要求,也是为了砍掉『CAA 复查』:验证数据超过 7 小时就得重跑一部分验证流程。除非你的 ACME 客户端特意依赖授权复用,否则不需要改任何东西。
官方给的动机很纯粹——证书寿命越短,密钥泄露和误签发的风险窗口越小,『作为非营利组织,我们认为推动这项变更、为全球 Web 用户提升安全是我们的使命。』rate limits 不受影响,ACME 端点和签发链也不变。
工程向的提醒倒是实在:这是顺手把证书 reload、部署和续期失败告警一起自动化掉的好时机。毕竟按这个路线图,证书只会越来越短命,人工盯着续期这条路迟早走不通。
来源: