证书续期规范落地：把“提前 30 天自动重签”写成团队约定，而不是靠人记
证书过期事故大多不是工具不行，而是没人规定“谁来签、何时签、失败怎么办”。本文给出一条可直接执行的续期规范：自动签发到期前 30 天重签、失败逐级告警、部署留痕，并说明它在哪些场景下不适用。
线上证书过期的事故，复盘到最后常常很尴尬：证书工具早就装好了，crontab 里的 renew 也在跑，但没人确认它跑成功了。告警发到一个人人都不看的邮箱，等用户报障才发现。所以证书运维规范的核心不是选哪个工具，而是把三件事写成明确约定：签发时机、失败处理、部署责任。
一条可执行的续期规范
到期前 30 天自动重签，失败立即告警。 Let's Encrypt 证书有效期 90 天，留出 30 天意味着即使自动续期连续失败多次，也有充足时间人工介入。不要把续期窗口压到 7 天以内——那等于把每次 DNS 抖动、ACME 接口波动都变成潜在的深夜告警。
重签和部署必须是同一条流水线。 只重签不部署是最常见的假成功：磁盘上的新证书躺着，Nginx 还加载着旧证书。规范里要写清楚：签发成功后自动 reload 或推送证书到实际使用它的组件，并记录这次部署——什么时间、哪台机器、哪个证书。
告警分级。 第一次续期失败发普通通知即可，连续失败或距到期不足 14 天仍未成功，升级到需要人工确认的渠道。所有失败都发同一个群，结果只能是全体免打扰。
每月抽查一次。 自动化不等于免维护。每月花十分钟看一遍部署记录和到期时间分布，能提前发现“某台机器悄悄掉队”这类监控盲区。
在 CertbotX 中实践
这条规范在 CertbotX 里有直接的对应实现：通过 DNS-01 的 CNAME 委托完成域名验证（适合 DNS 权限不方便直接下放给签发服务器的场景），ACME 自动签发并在到期前自动重新签发，签发成功后自动部署到 Agent、EdgeOne 或 CDN，每次部署都有记录可查。也就是说，上面规范里的“重签即部署、部署留痕”不需要自己拼脚本，抽查时直接翻部署记录就能确认每台服务是否拿到了新证书。需要注意的是，自动部署只覆盖已接入的目标；临时手动挂载证书的旧服务，仍然要人工纳入抽查清单。
适用边界
这套规范默认的前提是：证书由 ACME 类自动签发体系管理，有效期较短，且服务支持热加载证书。以下情况它帮不上忙：
- 内网私有 CA 或长有效期 OV/EV 证书。 一年一签的证书靠日历提醒加双人复核更实际，自动化收益低，反而容易因为一年才跑一次而生锈。
- 不支持热加载的老服务。 如果换证书必须重启且服务有可用性要求，部署窗口需要单独排期，不能跟着自动续期走。
- 域名验证依赖人工操作的场景。 比如 DNS 解析在第三方客户手里，CNAME 委托没配好之前，任何自动续期都是空谈。先把验证链路打通，再谈规范。
规范写得再细，也只是把“大概率不出事”变成“出事了能提前知道”。真正的分水岭在于：失败告警是否有人在看。
