一条能落地的证书运维规范：签发后 30 天内完成部署并下线旧证书
证书躺在工单系统里没部署、旧证书到期前一天才有人想起，是最常见的两类线上事故源头。这篇讲一条简单的内部规范——签发后 30 天内完成部署并下线旧证书——以及它在哪些场景不适用。
本文目录
很多证书事故不是技术问题，而是流程缺口。典型现场是这样：运维提前 40 天续好了证书，文件放在某个目录里，想着"下周上线"。然后下周变成了下下周，直到某个深夜，线上告警响了——旧的已过期，新的还躺在那儿，两边差着一次部署。
针对这类问题，我见过比较好使的一条内部规范是：证书签发完成后 30 天内必须完成部署并下线旧证书。它简单、可检查、责任清楚，比"及时更新证书"这种口号有效得多。
这条规范具体管什么
拆开是三件事：
- 签发和部署是同一个工单。谁申请续签，谁负责把它推到线上，不允许"签发即完成"。
- 30 天是部署窗口，不是提醒窗口。Let's Encrypt 证书有效期 90 天，在剩余约 30 天时完成续签和部署，意味着部署动作发生时新证书还有完整的使用期。如果 30 天到了还没部署，工单直接升级，而不是再发一条提醒邮件。
- 部署后明确下线旧证书。很多人忘了这一步，结果负载均衡器上一半实例用新证书、一半用旧证书，客户端报错的复现概率变成玄学。下线动作包括：移除旧证书文件、重载服务、确认所有入口返回的都是新证书链（用
openssl s_client -connect 域名:443 -servername 域名逐个入口抽查）。
配合两个习惯会顺很多：重载而不是重启（Nginx 的 reload 足够加载新证书），以及部署后用浏览器和命令行各验一次，别只信监控探针——有些探针只查 TCP 通不通。
在 CertbotX 中实践
手动跑这条规范最大的负担在"谁记得"。CertbotX 里可以把 ACME 自动签发和到期前重新签发配好，再把部署目标设为 Agent、EdgeOne 或 CDN，签发完成后自动推送，工单里最容易漏的那一步就没了。泛域名证书走 DNS-01，如果主 DNS 不方便开 API 权限，可以把 _acme-challenge 子域 CNAME 委托到一个专门用于验证的 DNS 区。每次部署都会留记录，审计时能直接回答"这张证书什么时候、由谁、部署到了哪里"，这正是"30 天窗口"可检查的前提。
适用边界：这条规范管不到的地方
先说清楚它不适合谁，比吹嘘它多有用更诚实。
短有效期证书：如果有人已经在用 7 天有效期的内部证书，"30 天部署窗口"这个概念本身就不成立，那条路线下部署必须全自动，规范应该是"任何环节人工介入视为故障"。
客户端证书和内部 mTLS：这类证书往往嵌在设备固件、IoT 终端或第三方系统里，部署周期以月甚至以年计，30 天下线旧证书不现实。这里需要的是双证书并行信任期，而不是快速下线。
证书被吊销的紧急情况：私钥泄露时不是"30 天内"，是"尽快"，而且顺序反过来——先吊销、先切换，再补流程。这条规范管的是常规轮换，不是事故响应。
你无法控制部署的证书：比如证书在客户自己的设备上，你只能交付文件。这时规范该约束的是交付和确认，而不是部署时限。
一个小坑
规范里写"30 天"的时候，记得对齐续签触发点。如果自动化在到期前 30 天才触发续签，签发和部署窗口就重叠了，出问题时没有缓冲。更稳的做法是到期前 45 天左右触发续签，签发成功后留 30 天部署窗口，最后还有 15 天兜底。缓冲这东西，平时看着浪费，出事那天就是全部。
另外，规范落地前先盘点一遍现有证书的在哪、谁负责。不少团队的证书台账和实际线上情况对不上，规范写得再漂亮，管不到一张没人知道的证书。
参考核验
- Let's Encrypt 文档：证书有效期与续签机制 — 核验 90 天有效期和续签建议
- RFC 8555：ACME 协议 — 核验 DNS-01 验证与自动签发流程
- Nginx 官方文档：HTTPS 服务器配置 — 核验证书链配置与重载行为