按每年更换一次证书安排运维周期的做法，自 2026 年 3 月起已不再适用。
CA/浏览器论坛（CA/Browser Forum，下称 CA/B 论坛）于 2025 年 4 月投票通过 Ballot SC-081，为公共信任证书确定了三阶段压缩路线：200 天 → 100 天 → 47 天。第一阶段已于 2026 年 3 月 15 日生效。
此次压缩的范围不止有效期，还包括域名控制验证（Domain Control Validation，DCV）结果的复用期。后者对手工流程的约束更为直接。
有效期上限的演变
从 5 年压缩至 47 天，降幅约 97%。此前每一轮调整后，业界均普遍认为已接近下限。
缩短有效期与修复吊销机制的取舍
证书泄露后直接吊销，看似更为直接。但吊销机制在实际互联网环境中始终未能可靠生效：
- CRL（证书吊销列表） 体积随吊销量线性膨胀，客户端下载和解析成本高，更新有延迟。
- OCSP（在线证书状态协议） 引入了额外的网络往返，暴露用户访问了哪个站点（隐私问题），而且 OCSP 响应者本身会成为可用性瓶颈。
- OCSP Stapling 能解决隐私和延迟问题，但部署率始终上不去，而且需要服务器正确配置。
- 最关键的一点：出于可用性考虑，浏览器普遍采用**软失败（soft-fail）**策略，即无法获取吊销状态时默认放行。具备流量拦截能力的攻击者只需一并拦截 OCSP 请求，即可使吊销失效。
Let's Encrypt 已于 2025 年停止提供 OCSP 服务，仅保留 CRL，可视为生态对该路线的实际结论。
在主动吊销不可靠的前提下，替代方案是缩短证书自身的有效期。有效期是唯一不依赖在线查询、不受中间人拦截影响的失效机制，其生效时间是确定的。以确定的过期时间替代不确定的吊销生效时间，是整条路线的基本逻辑。
第二项动机是算法敏捷性：短有效期使整个生态能更快完成加密算法切换。在后量子迁移的背景下，若五年前签发的证书仍在流通，算法升级无法在合理周期内完成。
域名验证复用期：更实质的约束
多数讨论集中在年度续期次数上，但这一部分相对容易解决，通过定时执行 certbot renew 即可覆盖。
更实质的约束来自 SC-081 的另一半：DCV 复用期同步压缩，2029 年将降至 10 天。
当前多数组织的流程为：申请证书时由运维在 DNS 控制台手工添加 _acme-challenge TXT 记录，验证通过后该结果可复用较长时间，后续续期无需再修改 DNS。
复用期降至 10 天后，该流程不再可行——需要自动化的不仅是签发，还包括每次重新完成域名验证。任何依赖人工操作 DNS 控制台的环节，都将变为每年触发数十次的高频操作。
这也是 IETF 中 dns-persist-01、dns-account-01 等持久化验证扩展出现的直接动因：在验证结果不可长期复用的前提下，保持 DNS 验证的可自动化性。
续期频率的实际影响
从每年 1 次增至 8 次，运维负担的增长并非线性：
- 每年 1 次：可纳入年度计划，人工操作出错后有充足的补救时间。
- 每年 4 次：需要专人跟踪，节假日与人员休假成为风险点。
- 每年 8 次叠加 10 天验证复用期：每次续期均需重新完成域名验证。以 50 个域名计，年验证操作约 400 次，该量级下任何人工环节都将成为故障来源。
应对方案
按投入规模由小到大，分为三个层次：
一、接入 ACME
自动证书管理环境（Automatic Certificate Management Environment，ACME，RFC 8555）是该问题的标准方案。成熟客户端包括 certbot、acme.sh、lego 以及面向 Kubernetes 的 cert-manager。
选择验证方式时值得注意：
- http-01 最简单，但要求 80 端口可从公网访问，不支持通配符证书。
- dns-01 支持通配符与内网服务，但需要 DNS 提供商的 API 权限。在复用期缩短的前提下，确认 DNS 提供商提供可用 API，且密钥权限范围足够收敛，其重要性高于客户端选型。
- tls-alpn-01 走 443 端口，适合 80 端口不可用的场景。
二、将 TLS 终结收敛到网关
证书分散在数十台服务器上时，自动化复杂度呈乘法增长。将 TLS 终结收敛至反向代理、负载均衡或服务网格入口，可使证书数量下降一个数量级。
Caddy、Traefik 原生集成 ACME；Nginx 可以配合 cert-manager 或 acme.sh 的 reload hook；云上的 ALB / CLB 大多提供托管证书。
三、监控对象应为自动化流程而非到期时间
这一步最容易配置错误。多数团队的证书监控设置为到期前 30 天告警；在 47 天有效期下，该阈值意味着证书签发不足三周即开始告警，很快会被视为噪音而忽略。
监控对象应为：
- 续期任务是否按预期执行：以距上次成功续期的时长为指标，而非距过期的剩余时长
- 验证环节是否失败：DNS API 调用失败、权限过期、触发限流
- 新证书是否已实际加载：续期成功但服务未重载是最常见的失败形式
- CT 日志侧的交叉验证：从外部视角确认线上证书已完成更换
常见问题
结语
证书有效期的压缩表现为运维工作量增加，实质是一次责任转移：从依赖人工记忆续期，转为由系统保证续期。
47 天这一数值本身并非终点，其指向的趋势是：有效期将持续压缩至自动化流程可承受的边界，而非人工流程可承受的边界。提前完成自动化建设后，后续每一轮收紧均只需调整配置参数。
参考资料