证书到期前 30 天就该重签：一条能落地的证书运维规范及其边界
给出一条可执行的证书生命周期规范：到期前 30 天续签、签发与部署分离、部署必须可审计、失败要有人收到告警。同时说明这条规范在哪些场景不适用，比如短寿命证书、内网 CA 和手动流程遗留系统。
本文目录
半夜被"证书还有 3 天到期"的告警叫醒过几次之后，大多数团队都会写一个自己的续签脚本，然后发现脚本本身成了新的风险源：它静默失败、它只签不发、它部署完没人知道。问题从来不是"会不会签证书"，而是有没有一条谁都能照着执行、出问题能追责的规范。
下面这条规范不追求覆盖所有场景，只解决一件事：让证书过期这类事故从"看运气"变成"不可能悄悄发生"。
规范本身
签发和部署分成两个动作，各自留记录。 拿到证书不等于换上证书。很多事故的根源是续签成功了，但新证书躺在磁盘上，Nginx 还加载着旧的。规范要求：每次签发完成后必须有一次显式的部署动作，部署动作要写入审计日志——什么时间、哪个域名、部署到了哪台机器或哪个平台、新证书的到期时间是多少。
提前 30 天发起续签，留足重试窗口。 Let's Encrypt 证书有效期 90 天，在剩余 30 天时续签意味着即使第一次失败，还有约一个月时间修。不要把重试逻辑写成"失败就明天再来"然后没人看日志——失败必须触发告警，且告警要发到人会看的渠道。
域名验证方式优先用 DNS-01 加 CNAME 委托。 HTTP-01 要求 80 端口可达且路径不被 CDN 或 WAF 拦截，在多节点、多 CDN 的环境里很容易翻车。把 _acme-challenge 记录 CNAME 到一个专门的验证域，主域的 DNS 提供商支不支持 API 就不再是瓶颈，泛域名证书也只能走这条路。
私钥不出不该出的地方。 证书可以分发到边缘节点，私钥的传输路径要明确：走加密通道，落盘权限收紧，禁止出现在日志和工单系统里。
在 CertbotX 中实践这条规范时，DNS-01 的 CNAME 委托、ACME 自动签发和到期前重新签发是内置流程，不需要自己拼 cron 加脚本。签发完成后可以自动部署到 Agent、EdgeOne 或其他 CDN，每次部署都有记录可查——审计那一条规范就靠这个落地，而不是靠运维自觉写变更单。
适用边界
这条规范不是万能模板，几个场景要单独处理：
- 短寿命证书环境。 如果你已经在用几小时或几天有效期的内部证书方案，"提前 30 天续签"的数值没有意义，但"签发与部署分离、失败有告警"这两条仍然成立。
- 内网私有 CA。 ACME 流程走不通的地方，规范的验证方式部分不适用，签发节奏要看私有 CA 自己的策略。
- 证书绑定在硬件设备或第三方 SaaS 上。 比如证书要手动上传到某台负载均衡设备，自动化部署到不了的地方，至少要保留"到期提醒 + 人工确认回执"，让流程断在明处。
- 通配符证书被多方共用。 一张
*.example.com部署到几十个服务时，更换证书的影响面远大于单域名证书，部署动作需要分批并保留快速回滚到旧证书的能力（在旧证书未过期且未被吊销的前提下）。
规范的价值不在文档里，在于每条都能指着一条日志或一个告警说"这条被执行了"。写不出来的部分，往往就是下次事故的来源。
参考
- Let's Encrypt 文档：续签与集成建议 — 核对有效期、续签时机的官方说明
- RFC 8555：ACME 协议 — DNS-01 等验证方式的标准定义
- Nginx HTTPS 服务器配置 — 部署证书时的配置参考