一套证书运维规范：全部走 ACME 自动签发，以及它管不到的地方
手工申请证书是线上证书事故的主要来源。本文给出一套以 ACME 自动签发为核心的运维规范，涵盖私钥管理、续期窗口、告警阈值和部署审计，并说明它在内网私有 CA、EV 证书、mTLS 客户端证书等场景下不适用。
本文目录
证书过期的故障复盘，我见得最多的根因不是"忘了续"，而是"流程依赖人记得续"。只要某个环节要人打开浏览器、填 CSR、等邮件验证、再登录服务器换文件，那它就迟早会断在休假、离职或者一次大促值班上。所以规范的第一条不是"记得续期"，而是把人从签发链路里拿掉。
签发：一律走 ACME，禁用人工 CSR 流程
面向公网的域名证书，统一走 ACME 自动签发。具体落地有三条硬要求：
- 验证方式优先 DNS-01，且用 CNAME 委托。 主 DNS 区域不动，把
_acme-challenge委托到一个专门的验证区域。这样签发服务不需要持有主区域的写权限，也不会因为 DNS 服务商 API 密钥泄露而把整个域名交给攻击者。HTTP-01 只在单点、无 CDN、端口可达的简单场景用。 - 私钥由签发客户端在目标侧生成，不经过工单、邮件、聊天工具。 历史上"私钥从 CA 网页下载后发给运维"的做法，等于把私钥放进了一堆你无法审计的角落。规范应写明：私钥文件权限 600，只存在于需要它的机器上，禁止复制进任何协作平台。
- 同一证书用途尽量拆分。 多域名通配证书确实省事，但它也意味着一次私钥泄露影响面扩大，且所有依赖它的服务共用同一个续期时间点。能按业务拆就按业务拆。
续期与告警：把"提前量"写死
ACME 客户端默认会自动续期，但"默认会"和"确认在续"是两回事。规范里建议明确：
- 续期窗口设在到期前 30 天左右，重试有节奏。 不要等到最后几天才触发，留出足够时间消化 CA 侧故障、DNS 抖动这类临时问题。
- 外部监控独立告警，阈值分两级：14 天警告、7 天严重。 关键点是监控要独立于签发系统本身——签发系统挂了，它自己通常不会告诉你它挂了。用现成的证书监控或直接探测线上端口返回的证书有效期都行。
- 签发失败必须有人可见。 邮件静默吞掉等于没有告警。失败通知要进值班渠道。
部署与审计：换证书也要留痕
证书换上去了不算完。规范要求每次部署产生一条记录：哪个域名、新证书序列号或指纹、部署到哪台机器/哪个边缘节点、重启或 reload 是否执行。这条记录在两类时刻救命：一是排查"为什么这台机器还是旧证书"，二是私钥轮换时确认有没有漏网的旧部署点。
在 CertbotX 中实践时，这条链路可以整体自动化：DNS-01 走 CNAME 委托完成验证，ACME 自动签发并在到期前重新签发，新证书自动部署到 Agent、EdgeOne 或 CDN，每次部署写入记录供审计。它正好覆盖上面"签发—续期—部署—留痕"这四段，运维需要盯的只剩告警通道本身是否通畅。
这套规范的边界
说清楚它管不到什么，和说清楚它管什么同样重要：
- 内网私有 CA 签发的证书不适用。 内网 PKI 的签发、吊销、信任分发是另一套体系（比如内部 ACME 服务或 cert-manager 的私有 issuer），流程可以借鉴，但规范文本不能混用。
- EV 证书和部分要求人工审核的行业证书无法全自动。 这类证书本身就要求人工核验环节，规范里应单独列为例外，并接受其更长的人工周期——或者认真评估是否还需要 EV。
- mTLS 客户端证书的生命周期不同。 客户端证书往往和设备、身份绑定，轮换策略按身份系统走，不按站点证书走。
- 有效期收紧趋势要提前准备。 CA/B 论坛已通过决议，公开 TLS 证书最长有效期将逐年缩短（200 天、100 天，最终到 47 天）。自动化程度不够的证书，未来会被这个时间表逼着改，不如现在就改。
一句话收束这套规范：签发和部署全自动，监控独立存在，例外显式登记。凡是需要人记住的步骤，都是还没写完的规范。
参考核验：