摘要

  • CA/Browser Forum 当前周期把公开 TLS 订户证书的最长有效期限制为 200 天；2027 年 3 月起降至 100 天，2029 年 3 月起降至 47 天。
  • 有效的成功指标不是“证书已签发”，而是预期终止点中有多少已被外部观测为提供获批的新证书，并且仍留有足够的故障恢复时间。

设想凌晨两点，中央证书服务完成了一笔 ACME 订单，控制台显示绿色。大多数负载均衡器拿到了新证书，但一个区域 API 网关和一个邮件端点仍在提供旧证书。签发没有失败，续期却没有完成。组织内部出现了两个时钟：证书机构记录的状态，以及真实终端集群的状态。

有效期越短，这个差距越昂贵。CA/Browser Forum 现行基线要求规定，2026 年 3 月 15 日至 2027 年 3 月 15 日前签发的订户证书最长为 200 天；随后降至 100 天，并在 2029 年降至 47 天。域名和 IP 地址验证数据的可复用期也同步收紧，到 2029 年只有 10 天。

这不是要求所有证书都用满上限。Let’s Encrypt 已在 2026 年 5 月为自愿采用者启用 45 天的 tlsserver ACME 配置，并计划分阶段缩短默认配置。它要求使用者确认自己的自动化能够适应更短的证书。

证书变短，意味着控制闭环变快

算术很简单：有效期越短，续期越频繁。困难在于，每个周期都依赖一条完整链路：明确的标识符、可用的域名控制验证、仍受控的 ACME 账户、能够下单的客户端、能够分发的机密通道、能够重载的服务，以及能够从外部证明结果的观察点。

RFC 8555 自动化了其中许多环节，也清楚划出了权限边界。ACME 客户端用账户密钥签名请求。在账户范围内，掌握这把密钥的人可能执行签发、吊销、账户变更与密钥轮换。因此，续期自动化同时集中了一项重要权限，不能把账户密钥当作普通定时任务的附属品。

部署端也有同样的问题。证书机构可以成功签发，却不知道所有反向代理、入口控制器、CDN 边缘、设备管理界面或邮件服务是否都需要更新。新证书可以已经进入机密仓库，但某个长期运行的进程仍在提供旧证书。更糟的是，一个终止点可能根本没有出现在中央清单里。

这些是不同故障，不应被压缩成一个绿色的“续期成功”。

ARI 调整时间，不能替订户完成部署

RFC 9773 定义了 ACME Renewal Information。支持它的证书机构可以给出建议续期窗口，客户端也可以声明新订单将替换哪张旧证书。这样既能平滑签发压力，也能在特殊情况下要求提前续期。

ARI 的价值在于固定规则会过时。证书只有 45 天时，“到期前 30 天再续”已经不再是稳健的默认值。建议窗口让证书机构可以调整节奏，而不必让每个订户把当前产品周期写死在代码里。

但 ARI 只协调替换的起点。它不能证明新证书已经安装，不能证明正确证书链正在提供，也不能证明所有目标边缘节点已经更新，更不能证明外部客户端可以完成握手。完成条件仍然是可观测的集群状态。

Let’s Encrypt 的集成指南因此建议至少每天两次检查 ARI，保留基于剩余有效期的后备规则，把大规模证书集拆成小批次，并随机化运行时间。其 2026 年关于 Shopify 的案例描述了保存续期窗口并持续轮询，而不是依赖一个静态阈值。那是有来源归属的运营案例，不是所有订户的通用证明。

稀缺资源是可用的恢复余量

更短的有效期能减少陈旧凭据继续被接受的时间，也压缩了处理域名验证故障、账户失效、客户端限流、机密同步失败、服务重载不兼容或遗漏终止点的日历。

所以关键指标不是续期次数，而是可用恢复余量：第一次失败到证书到期之间，扣除发现、找人负责、修复、重新部署与独立验证后还剩多少时间。

提前、小批量续期，配合有界重试与外部证明，可以在不显著增加可用性风险的情况下获得安全收益。相反，一次性批量续期、只相信订单成功、无人负责尾部失败，会把计划内控制变成同步故障。

公开资料无法说明某个具体订户属于哪一种。它们不包含私有终止点清单、故障预算、客户端版本、账户保管方式或事故记录，也不能证明短证书已经消除了吊销与密钥泄露风险。能够成立的结论更窄：时间表提高了替换证据的价值，也让陈旧假设更快变得不可承受。

来源