证书到期告警总在最坏的夜里响：一条能落地的续期运维规范
证书过期事故大多不是技术问题，而是续期流程没人兜底。本文给出一条可落地的证书运维规范——自动签发、提前续期、部署留痕、保留人工兜底，并说明它在哪些场景下不适用。
本文目录
---
很多团队的证书管理现状是这样的：申请靠某个人记得去点，部署靠另一个人记得去换，告警靠监控平台在到期前两天发一封没人看的邮件。然后某天凌晨，CDN 回源握手失败，值班的同事翻遍群聊才找到当初是谁签的证书。
这类事故几乎没有技术门槛，纯粹是流程问题。所以规范也应该按流程来立，而不是按工具来立。
规范本身：四句话
我推荐的规范很简单，四句话就能说完：
- 所有公网证书走 ACME 自动签发，不允许手工下载再上传。 手工流程是事故的温床——人会离职、会休假、会忘。Let's Encrypt 这类 90 天有效期的证书，本来就是按"你会自动化"这个前提设计的。
- 续期时间固定在有效期剩余三分之一处，并留重试窗口。 以 90 天证书为例，剩 30 天左右触发续期，失败了还有二十多天可以重试和告警，而不是最后一天孤注一掷。
- 签发和部署必须是同一条流水线，且每一次部署留下记录。 证书签下来但没推上服务器，等于没签。谁能查到"这个域名上次换证书是什么时候、推到了哪几台机器"，故障时就能少排查一半。
- 保留一条人工兜底通道。 自动化卡死时（CA 限流、DNS 校验失败），值班的人应该知道去哪里手动补发，而不是从零研究 ACME 协议。
几个容易踩的坑
DNS-01 校验时别把主域名权限交出去。 用 CNAME 把 _acme-challenge 记录委托到一个专门用于验证的 DNS 区域，自动化系统只拿那个区域的 API 权限。这样 DNS 凭据泄露的爆炸半径就小得多——凭据管理不当引发的麻烦，往往比证书过期本身更难看。
多节点、多入口的场景要统一出口。 同一个域名后面挂着 Nginx 集群、CDN 和边缘节点时，证书必须推齐。只更新了源站忘了 CDN，或者反过来，用户看到的就是薛定谔的 HTTPS——有的人能开，有的人报错，排障体验极差。
通配符证书不要当成万能胶。 一张 *.example.com 铺满所有环境，意味着一处私钥泄露全环境换证。通配符适合同一团队、同一信任域的多个子域，跨团队就该拆开签。
在 CertbotX 中实践
上面四条在 CertbotX 里基本能原样落地。DNS-01 走 CNAME 委托，把挑战记录指向受控的验证区域，不用交出主域 DNS 权限；ACME 自动签发后由系统在到期前重新签发，不需要人肉记日子；签发完的证书可以自动推送到 Agent 管理的机器、EdgeOne 或 CDN，签发和部署是同一条链路；每次部署都有记录可查，出事时能直接回答"证书推到哪了、什么时候推的"。人工兜底通道仍在——自动化失败时可以直接在控制台介入，不影响既有流程。
适用边界
这条规范不是到处都灵，说清楚边界比吹它万能更有用：
- 内网或私有 CA 体系。 如果你的证书来自企业私有 CA，ACME 未必适用（除非 CA 支持 ACME 端点），续期策略也要按私有 CA 的签发规则调整。
- OV/EV 证书。 涉及人工审核流程，不可能纯自动续期，只能自动化部署环节，签发仍要留人工排期。
- 强合规要求的密钥管理。 某些行业要求私钥不出 HSM 或特定密钥管理系统，自动化部署的私钥分发路径需要另行评估。
- 客户端证书、mTLS 双向认证。 那是另一套生命周期管理，和服务器证书的运维模型差别很大，别混为一谈。
另外提醒一句：规范落地后，把"证书快过期"的告警留着但调低优先级。自动化正常工作时它应该永远不响；它真响了，说明自动化坏了——这才是它真正的用途。
参考核验
- Let's Encrypt 官方文档：集成与续期相关说明 — 核对 ACME 签发流程、有效期与速率限制
- RFC 8555：ACME 协议规范 — 核对 DNS-01 等挑战类型的协议定义
- Nginx HTTPS 服务器配置文档 — 核对证书在服务器侧的加载与多证书配置方式