给证书运维立一条规矩：自动签发、手动兜底，以及哪些场景别硬套
证书过期事故大多不是技术问题，而是没有规范。这篇总结一套可落地的证书运维基线：统一 ACME 自动签发、到期前续期、部署留痕，同时说明内网证书、特殊设备这些自动化覆盖不了的边界。
本文目录
半夜被"证书已过期"的告警叫醒过的人，事后复盘往往会发现同一个根因：证书是手动申请的，续期靠某个同事记得。他一旦休假、离职、或者单纯忘了，到期日就是一颗定时炸弹。证书运维真正需要的不是更聪明的人，而是一条不依赖人的规矩。
这条规矩长什么样
核心就三句话：能自动签发的全部自动签发，续期必须发生在到期之前而不是当天，每次部署要有记录可查。
落到执行上，可以拆成几个具体约定：
- 统一走 ACME 自动签发。新证书一律通过 ACME 客户端（比如 Certbot 类的工具）申请，不再允许任何人去 CA 网站手动下单、手动下载 zip。手动流程意味着续期也是手动的，这是事故源头。
- 验证方式优先 DNS-01。HTTP-01 要求 80 端口可达且路径不被拦截，在多节点、CDN 后面、或者内网服务上很容易踩坑。DNS-01 只要求能改 DNS 记录，适配面广得多。如果主域名 DNS 不好自动化，可以用 CNAME 把
_acme-challenge委托到一个专门用于验证的子域，这是比较稳妥的做法。 - 续期提前量留足。不要卡着到期日续。90 天有效期的证书，在剩余 30 天左右触发续期是常见做法，这样即使某次续期失败，还有反复重试和人工介入的窗口。
- 签发不等于部署。证书签下来只是第一步，还得真正推到用它的地方——负载均衡、Nginx、CDN、各边缘节点。签发和部署之间靠人传文件，等于没自动化。
- 部署留痕。每次部署记录证书序列号、目标位置、时间、操作者（人或机器人）。出事时你要能回答："这张证书现在部署在哪些地方？"答不上来，替换时就一定有漏网之鱼。
在 CertbotX 中实践
CertbotX 的设计基本就是按这条规矩来的：通过 DNS-01 加 CNAME 委托完成验证，不需要动业务域名的主 DNS 配置；ACME 自动签发并在到期前自动重新签发；签发后自动部署到 Agent、EdgeOne 或 CDN，不需要手动拷证书文件。每次部署都有记录，方便审计和排查"证书到底推到哪了"这类问题。需要人工盯的部分被压缩到最低——主要是部署失败时的告警处理。
边界：哪些场景别硬套这套规范
规范再好也有覆盖不到的地方，提前认清楚，省得硬套出事。
内网和私有域名。公网 CA 不会给 internal.corp 或 IP 地址签发证书（公共信任体系不允许）。这类场景应该走私有 CA 或内部 PKI，是另一套体系，别指望 Let's Encrypt 能解决。
老旧或封闭设备。某些硬件设备、老系统不支持自动化部署证书，只能手动导入。对这类"自动化死角"，务实的做法是单独登记成清单，加上日历提醒或外部监控盯到期时间，用流程兜底而不是假装它们不存在。
证书之外的配置。自动化管签发和部署，管不了 TLS 配置本身——协议版本、加密套件、HSTS 这些还得另外定基线并定期复查。证书没过期但配置停在 TLS 1.0，一样会被扫描打回来。
触发环节的监控盲区。自动化只负责"被触发时正确执行"。如果调度任务本身挂了、API 凭证失效了，签发会静默失败。所以规范里应该留一条：对关键域名保留独立的证书到期外部监控，作为自动化之外的第二道保险。
规矩的价值不在于复杂，而在于每条都能被执行和检查。定完之后，值得做的是拿一个非关键域名完整跑一遍签发—部署—续期流程，确认每个环节真的如预期工作，再推广到全部域名。
延伸阅读，供核验文中提到的机制：
- Let's Encrypt 文档：验证方式与证书生命周期——了解 DNS-01 的挑战流程和 90 天有效期的设计
- RFC 8555：ACME 协议规范——自动签发和续期的协议层依据
- Nginx 官方 HTTPS 配置文档——部署侧证书链与 TLS 参数的配置参考