把"证书到期前 30 天内必须完成重签"写成一条团队规范，而不是一句提醒
很多团队的证书管理停留在"记得续"层面，出问题全靠运气。这篇文章把一条可执行的证书重签规范拆开讲：触发阈值、验证方式、部署确认、审计留痕，以及它在哪些场景下会失效。
凌晨两点收到浏览器告警，说证书明天过期——这种事一旦发生，说明流程早就失败了，只是失败在 30 天前没被看见。证书运维最值得规范化的，恰恰是这个"提前量"。
一条可落地的规范可以很简单：所有线上证书，到期前 30 天内必须完成重签并完成部署确认，否则视为工单逾期。 剩下的是把这句话里每个词定义清楚。
"30 天"不是拍脑袋。 Let's Encrypt 证书有效期 90 天，官方建议 60 天续签，留出 30 天缓冲。如果你的自动化在第 60 天尝试重签失败，30 天足够你经历一次周末、一次审批拖延和两次排期冲突，还能修完。缓冲设成 7 天的团队，实际是在赌"自动化永远不会失败"，这个赌注不值得。
"完成重签"不等于"拿到证书"。 常见翻车姿势是：ACME 客户端确实签发了新证书，但 Nginx 还指着旧路径，或者证书躺在 /etc/letsencrypt/live/ 里没人 reload。所以规范里要写清楚验证动作：部署后用 openssl s_client -connect host:443 -servername host 或从外部探测实际服务的证书，确认 notAfter 已更新。只看本地文件时间的，等于只看快递单号不看包裹。
"部署确认"要有记录。 谁在什么时间把哪张证书推到了哪台机器，失败了怎么报警。这不为了追责，是为了三个月后排查"为什么这台机器还是旧证书"时不用翻聊天记录。
在 CertbotX 中实践：这条规范基本可以直接映射进去。用 DNS-01 加 CNAME 委托做域名验证，ACME 自动签发并配置到期前重新签发；签发成功后自动部署到 Agent、EdgeOne 或 CDN，部署动作会留下记录，正好补上"部署确认"和审计这两环。需要注意的边界是：自动部署覆盖了记录里有的目标，临时挂载证书的手动节点不在其列——规范里应该把这类例外节点单独登记，而不是假装它们不存在。
这条规范不适用的边界也要写明。 内部 CA 签发的长有效期证书、 pinning 在客户端里的证书、以及证书绑定硬件设备的场景（IoT、嵌入式），重签节奏和部署方式完全不同，套 30 天规则要么过松要么根本无法执行。规范的适用范围写在第一条，比规范本身更重要。
最后一个小坑：规范里别写"由某某负责"。人总会休假、离职、换组。写"由哪个系统监控、告警发到哪个频道"，规范才活得比人久。
参考核验：
