best-practices

把证书轮换固定在到期前 30 天：一条能落地的运维规范及其边界

提出一条具体可执行的证书运维规范：所有证书在剩余有效期不足 30 天时统一轮换，并说明它的适用前提、与证书有效期、自动化工具的配合方式，以及哪些场景不适合照抄这条线。

凌晨两点的告警里，最常见的一种是“证书明天过期”。翻记录，证书是去年某天凌晨手动续的，当时顺手，现在没人记得流程。这类问题的根子通常不是技术，而是轮换没有成文的节奏：什么时候该续、谁来续、续完怎么确认，全靠记忆。

这里给一条可以写进运维文档的规范，再讲清它的边界。

规范内容

一句话：任何生产证书，剩余有效期小于等于 30 天时即触发重新签发，签发并部署成功后记录一次审计日志；连续两次自动轮换失败即升级为人工处理，人工处理的最晚期限是剩余 7 天。

拆开看有三个要点：

• 30 天是触发线，不是截止日期。 Let's Encrypt 的证书有效期是 90 天，把轮换点放在剩余 30 天，意味着正常情况下一张证书一年轮换四次左右，且每次轮换后还有整整一个月的缓冲来发现部署遗漏（比如某台机器没 reload）。
• 失败要升级，不能静默重试。 自动续期最怕“重试了但没成功，也没人看日志”。连续失败后必须有明确的升级路径——告警到人，而不是继续等下一次定时任务。
• 轮换完成以“部署生效”为准。 签发成功不等于轮换完成。验证方式是到每个实际提供 TLS 服务的端点上看证书链和有效期，而不是只看 ACME 客户端的输出。

为什么选 30 天而不是别的数

太短（比如剩余 7 天才续）会把任何一次验证故障变成紧急事故：DNS 服务商 API 抖动、CA 侧限流，都可能让你没有时间重试。太长（比如签发后立刻续）则浪费 CA 的额度，也增加无意义的变更面。30 天对 90 天有效期的证书是一个顺手的折中：留足故障窗口，又不至于频繁折腾。

这套节奏之所以成立，前提是验证方式可靠且自动化。HTTP-01 要求 80 端口可达且路径不被 CDN 或 WAF 拦截，在多节点、多 CDN 的拓扑里经常绊脚；DNS-01 用 TXT 记录验证，绕开入站流量的问题，更适合自动化场景。

在 CertbotX 中实践

CertbotX 支持 DNS-01，并且可以把验证用的 _acme-challenge 记录通过 CNAME 委托到一个独立区域，主区域的 DNS 权限就不用交给签发机器。签发后它会在到期前自动重新签发，并按配置把新证书部署到 Agent、EdgeOne 或 CDN，每次部署都有记录可查。把上面那条规范落进去，大致是：设好轮换触发点，盯住部署记录，把连续失败接到告警渠道，30 天线之前的部分交给工具，线之后的人工兜底留给人。

适用边界

这条规范不是万能的，几个不适合照抄的场景：

• 有效期不是 90 天的证书。 如果用的是一年期的 OV/EV 证书，30 天触发线依然可用，但“连续失败升级、7 天人工兜底”的紧迫性会下降，可以适当放宽。反过来，如果未来 CA 普遍缩短有效期（这个方向业界确实在讨论），缓冲窗口要按比例压缩，而不是死守 30 天。
• 证书绑定在硬件设备上。 负载均衡器、老款防火墙这类设备，部署新证书可能要重启服务或走专用 API，“签发即部署”未必成立，触发线要按设备变更窗口来排。
• 内部 CA 或私有 PKI。 内部证书通常有更长的有效期和自己的吊销流程，30 天线的意义不大，规范的重点应放在吊销和库存管理上。
• 需要人工审批的合规场景。 有些行业要求证书变更走审批单，自动化轮换和审批流天然冲突，这时触发线要提前到审批周期能跑完的位置。

另外一个小坑：轮换节奏定了之后，别忘了证书的私钥是否一起换。只换证书不换私钥，等于一直用同一把钥匙开新锁，轮换的安全收益会打折。

核验用资料

• Let's Encrypt 官方文档：证书有效期与续期建议 — 核对 90 天有效期和官方推荐的轮换节奏。
• RFC 8555（ACME 协议） — 了解 DNS-01 等验证方式在协议层面的定义。
• nginx HTTPS 服务器配置 — 部署后确认证书链与虚拟主机配置是否生效。