全球规模最大的免费数字证书颁发机构 Let's Encrypt 正式确认，从 2027 年 2 月 10 日起，其默认的 classic ACME 配置将全面切换为 64 天证书，彻底终结自 2016 年推行至今的 90 天标准。这一举措不是孤立的安全演进，而是对全球互联网基础架构运维逻辑的一次硬性出清。
表面上看，这是一次简单的有效期压缩，但 64 天这个不符合整数审美的跨度，精准暴露了自动化基础设施的脆弱现状。这既是 Let's Encrypt 领先整个公信安全标准整整一年的激进抢跑，也是对全球服务器里写死定时器脚本的一次集中排雷。
64 天背后的妥协：开源世界给僵尸脚本留了 4 天生路
在技术规范里，数字往往对应着严密的算法或规整的时间周期，例如 90 天、30 天或 7 天。为什么 Let's Encrypt 没有按照原定演进路线直接下探至 45 天，而是生硬地卡在 64 天？
答案藏在数以百万计的服务器后台里。Let's Encrypt 官方说明指出，行业内大量基于 cron 的自动化脚本或旧版部署工具中，写死了“证书生效后第 60 天续签”或“到期前 30 天轮询”的固定逻辑。如果机构一步到位将有效期切断至 45 天，这部分未经维护却仍在跑业务的自动化脚本将在第 60 天触发前全线过期，引发不可控的宕机事故。
设计为 64 天，本质上是给这些“写死 60 天”的僵尸任务保留了刚好 4 天的抢救窗口。运维人员即使没有更新轮询逻辑，也能在证书过期的边缘勉强续上一命，并从报警日志中意识到必须修改配置。按照官方路线，测试环境 Staging 将在 2026 年 10 月 14 日率先切换为 64 天；到了 2027 年 5 月 11 日，全球现存的最后一张 90 天证书将全部过期退出历史舞台。
缓冲期并不会持续太久。官方计划在 2028 年 2 月 16 日正式将默认配置压制到 45 天，彼时这 4 天的容错红利将被彻底剥夺。
提前一整年的抢跑：非营利先锋对商业阵营的降维施压
缩短证书有效期是整个网络信任体系的共同意志。在 CA/Browser Forum（简称 CA/B Forum）通过的 SC-081v3 系列决议中，全球公信 TLS 证书的有效期上限被切出了明确时间表：2026 年 3 月 15 日压缩至 200 天，2027 年 3 月 15 日压到 100 天，直到 2029 年 3 月 15 日才会最终收缩至 47 天。
商业证书颁发机构严格遵循这一底线。DigiCert 于 2026 年 2 月 24 日实施 199 天上限，计划在 2027 年 3 月 1 日降为 99 天，2029 年 3 月降为 46 天；Sectigo 也在 2026 年 3 月 12 日推行 199 天，计划在 2027 年 3 月 11 日实施 99 天。值得玩味的是，DigiCert 在此期间甚至出现过文档口径混乱，其通用常见问题中曾提及 2026 年 10 月进入 99 天，但官方信任日历最终仍锚定在 2027 年 3 月，反映出商业机构在应对频繁合规变更时的内部博弈。
Let's Encrypt 在 2028 年 2 月就要落地 45 天证书，比行业组织规定的 2029 年 3 月整整提前了 13 个月。它早就备好了更激进的选项：其针对特定服务商的 opt-in tlsserver 配置在 2026 年 5 月 13 日就已上线 45 天证书，甚至还额外提供了有效期仅 6 天的 shortlived 极短证书。
商业 CA 必须顾及企业级客户的人工运维惯性，不敢贸然加码；而生于自动化协议的 Let's Encrypt 没有任何历史包袱，它用激进的节奏迫使整个行业跟进，彻底消灭手动续签的生存空间。
真正的暗礁：授权复用期从 30 天跌至 7 小时
如果运维团队仅仅把这次调整看作修改定时器的数字，系统故障只是时间问题。比起证书有效期的变动，更具破坏性的是底层验证周期的剧烈收紧。
在自动化流程中，验证一次域名归属后，CA 会允许在一定时间内跳过二次验证直接发证，这被称为授权复用（Authorization Reuse）。过去，这一窗口期长达 30 天。根据 Let's Encrypt 新规，2027 年 2 月该复用期将直接腰斩为 10 天；到了 2028 年 2 月，这个窗口将被暴风骤雨般压制到 7 小时。
缩短天数只会淘汰懒惰，而压缩授权复用期则会直接击穿脆弱的架构。
过去一个月只需做一次 DNS 或 HTTP-01 验证即可应付多次证书申请，老旧脚本即使偶尔网络波动也能依靠缓存过关。一旦授权复用跌至 7 小时，意味着几乎每一次续期都是一次必须实时成功的端到端硬校验。这不仅消除了 CAA 记录复核带来的报错空间，也对那些依赖公网稳定性的老旧服务器提出了极高的容错要求。
- 风险.继续依赖固定时钟触发续签的服务器，由于缺乏动态调度，将在集中轮询时撞上更严苛的频次限制；而老旧 ACME 客户端对临时网络抖动的脆弱容忍度，会导致断签几率成倍增加。
放弃硬编码：ARI 协议重构自动化生命线
在 64 天乃至 45 天的时代，写死在 crontab 里的静态规则已经不可持续。行业正在完成一次代际切换：将续签的发起权从客户端完全交还给服务端。
解决方案是引入 ACME Renewal Information (ARI) 协议。在 ARI 机制下，不再由本地脚本根据 60 天或 80 天这类固定数字盲目轮询，而是由证书颁发机构根据负载均衡策略，在客户端查询时主动返回一个最合理的续订时间窗口。
更为关键的是频次限制差异。通过 ARI 发起的续期请求完全豁免于常规签发速率限制（Rate Limits）；而非 ARI 续期仍受到严苛的约束，例如相同标识符集合每 7 天最多 5 张证书，一旦在短周期内因网络故障反复重试失败，将直接面临被限流数天、整站无法签发有效证书的瘫痪绝境。
对于未全面适配 ARI 的遗留系统，Let's Encrypt 给出的保底建议是：必须将触发时间改为生命周期的 三分之二。对于 64 天证书，应在第 43 天发起续约；当 2028 年降至 45 天时，则需自动前移至第 30 天。
- 建议.立即排查基础设施中硬编码 83、80 或 60 等数值的定时任务，优先将 Certbot 等 ACME 客户端升级至支持 ARI 的版本，并在 2026 年 10 月 14 日测试环境就绪后完成真实链路演练。
从数年、398 天、90 天，一路狂奔至 64 天乃至 45 天，网络基础设施留给人工干预的缝隙已经彻底封死。安全证书不再是一张装在柜子里的长期许可证，而是演变成了一组在机器之间以天甚至以小时为单位无感流转的流动凭证。