证书续约别等 30 天：一条能落地的提前更换窗口规范

线上最气人的证书告警，往往不是"证书过期了"，而是"证书还有 3 天过期，自动续约已经连续失败一周没人看"。运维以为设了定时任务就万事大吉，结果验证方式失效、DNS 记录被改、CA 接口抖动，任何一个小问题都能在最后几天集中爆发。

问题出在哪？多数人把续约时间点设成了"到期前 30 天"这种拍脑袋值，却没有定义失败后的重试节奏和升级路径。这条规范就是来补这个窟窿的。

规范本身：三段式续约窗口

续约触发点设为有效期的 2/3 处。 90 天期的证书（比如 Let's Encrypt），在第 60 天左右发起续约，而不是第 75 天。这样即使第一次失败，手里还有 30 天的缓冲。对一年期证书，可以在剩余约 90 天时触发，逻辑一致：留出有效期的三分之一作为容错带。

失败重试要有节奏，不要每分钟狂刷。 第一次失败后按小时级间隔重试（比如每 6–12 小时一次），连续失败若干次（一个可执行的口径是 3 次）就停止自动重试，升级为告警，让人介入。原因很实在：持续失败通常意味着验证通道坏了（DNS 解析、HTTP 路径、防火墙），重试再多次也是同样的失败，反而可能撞到 CA 的速率限制。

告警阈值要早于续约触发点。 监控不该只盯"还剩 X 天过期"，还要盯"上次续约尝试是否成功"。一个健康的状态是：距离到期还很远时，续约已经悄悄完成了，日常巡检看到的是绿勾而不是倒计时。

几个容易踩的小坑

• 续约成功 ≠ 部署成功。证书签发下来但没 reload Web 服务，等于没换。规范里必须写明"签发后验证实际生效"，比如检查线上服务的证书序列号或 notBefore 是否更新。
• 多节点、多 CDN 的场景，续约后要确认所有边缘都拿到了新证书。负载均衡后面有一台机器还在用旧证书，监控可能抽查不到。
• 通配符证书只能走 DNS-01，DNS 凭据权限收得太死或 DNS 服务商 API 变更，是续约失败的常客。用 CNAME 委托把 _acme-challenge 指向专门 managed 的 zone，可以把凭据爆炸半径缩到最小。

在 CertbotX 中实践

这条规范在 CertbotX 里基本就是默认工作流：通过 DNS-01 加 CNAME 委托完成域名验证，ACME 自动签发并在到期前按窗口重新签发，失败有重试和记录可查。签下来的证书可以自动部署到 Agent、EdgeOne 或其他 CDN，避免"续了但没挂上"的断档；每次签发和部署都有记录，审计时能回答"这张证书什么时候换的、换到了哪里"，不用翻 shell 历史。

适用边界

这套规范假设你的证书生命周期以月为单位、签发走 ACME 这类自动化协议。几种情况需要变通：

• 内部 CA 签的短证书（几小时到几天）：2/3 窗口太短，应换成绝对缓冲时间，比如"剩余寿命小于 X 小时就续"。
• 需要人工审批的 OV/EV 证书：自动化窗口没意义，重点应放在提前发起流程和跟踪审批进度上。
• 无法自动验证的隔离环境：续约节奏要迁就人工操作窗口，告警阈值相应大幅提前。

一句话收口：续约不是"到期前执行一次命令"，而是一条带缓冲、带重试、带验证的流水线。把窗口留宽，把告警提前，证书这件事就可以重新变得无聊——而无聊，正是运维对它最高的赞美。

核验时可以参考：

• Let's Encrypt 官方文档：证书生命周期与续约建议
• RFC 8555：ACME 协议规范，理解自动签发与验证机制
• nginx 官方文档：HTTPS 服务器配置，核对证书部署与 reload 行为