把证书续签窗口定在到期前 30 天：一条可落地、也有边界的运维规范
证书事故大多不是签不出来，而是没人说清楚"什么时候续、续失败谁管"。本文给一条具体规范：到期前 30 天触发重签、失败三次即告警、保留回滚窗口，并说明它在哪些场景下不适用，比如多团队协作和第三方托管域名。
本文目录
线上翻车的证书，八成不是签不出来，而是"以为有人管"。ACME 自动续签早就普及，可事故复盘里最常见的结论还是那句：续签任务挂了三周，没人看告警。工具不缺，缺的是一条写清楚触发时机、失败处置和适用边界的规范。
规范本身：30 天窗口 + 三次失败即升级
以 90 天有效期的 Let's Encrypt 证书为基准，规范就三条：
- 到期前 30 天触发重签。不是到期前一周，更不是最后一天。30 天意味着即使整个重签流程彻底坏掉，你还有一个月的人工处置余量。这个时间还能躲开 CA 侧的偶发限流或验证通道临时故障。
- 连续三次重签失败即告警升级。自动任务单次失败很常见——DNS 传播慢、CA 临时抖动——所以单次失败只记日志。三次连续失败才打给人，间隔建议按小时算，不是按分钟刷。
- 重签后保留旧证书到服务确认加载成功。别签完就删。新证书部署后先验证服务实际加载的是新链（
openssl s_client -connect看 notAfter），再清理旧文件。部署中途进程没 reload 这种事，见过的人都懂。
这三条的价值不在技术，在于把"续签"从后台静默任务变成有明确责任界的运维动作：什么时候动、失败了找谁、什么时候算完。
在 CertbotX 中实践
这套窗口在 CertbotX 里可以直接落地：ACME 自动签发后，到期前自动重新签发，不需要人肉盯日历。DNS-01 验证支持 CNAME 委托——把 _acme-challenge 委托到专门的验证域名，主域 DNS 权限不用交给签发流程，这在主 DNS 由别的团队管的环境里尤其省事。签好后可以自动部署到 Agent、EdgeOne 或 CDN，部署动作留记录，满足上面"验证加载成功才算完"的审计要求。失败重试仍然建议按规范自己设告警，别把"自动"当成"不用看"。
边界：这套规范不适用的几种情况
证书有效期不是 90 天。随着 CA/B 论坛推动缩短证书有效期，未来窗口比例要跟着调。30 天是围绕 90 天证书设计的；如果有效期缩到 45 天级别，触发点应按比例前移，比如有效期的前 1/3 处。别死背数字，记住原则：窗口要大于"最坏情况下人工介入所需时间"。
多团队、多 CA 混用的环境。规范假设重签是单一自动化通道。如果一部分证书在 CDN 厂商托管、一部分自己签、一部分走企业 CA，"三次失败告警"要先按签发通道分组，否则告警噪音会让人三天内静音整个频道——然后事故还是照来。
证书之外的部分不归这条规范管。TLS 配置、协议版本、HSTS 这些是另一套变更流程，别混进证书续签的窗口里一起动。续签窗口内只做证书替换，顺手改配置是事故的经典配方。
规范的真正作用是给"一切正常"下个可检查的定义。续签任务有没有跑、新证书有没有加载、离到期还剩几天——这三件事能随时答上来，证书就基本不会再上事故复盘会了。
参考核对：