证书到期不再靠运气：一套能落地的巡检与告警运维规范

线上证书事故里，真正让人熬夜的往往不是加密算法过时，而是某个二级域名的证书在周日凌晨悄悄过期，监控群里一片红色，大家翻半天也说不清这张证书是谁、在哪、绑了什么服务。问题不出在技术上，出在没有一套谁都能照着执行的规范。下面这套做法在小到几台 Nginx、大到几十个域名的团队里都跑得动，先把结论说清：证书运维的核心就三件事——知道有哪些、知道什么时候到期、续签失败有人管。

建立唯一的证书台账

规范的第一条是消灭"散落"。证书信息必须收敛到一个地方，哪怕是一张共享表格，字段至少包括：

• 域名（含 SAN 覆盖范围）和证书类型（单域名/通配符）
• 签发 CA、签发方式（手动/ACME）
• 证书部署在哪些机器、哪些服务上
• 到期时间，以及"最后一次确认它活着"的时间

最后这个字段容易漏，但很关键。证书续签脚本可能静默失败两个月，而台账上写着"自动续签中"，直到告警炸了才发现。台账的意义不是记录配置，而是记录状态。

告警分级：30/14/7 天，而不是到期当天

到期当天告警等于没有告警。一套可落地的分级大致是：

• 到期前 30 天：低级别提醒，确认自动续签任务还在正常运行。
• 到期前 14 天：中级告警。如果此时还没续上，说明自动流程大概率出了问题，需要人工看一眼。
• 到期前 7 天：高级告警，直接电话或 IM 强提醒，因为这个窗口内 DNS 故障、CA 限流、授权失效都来得及救，但再晚就是赌运气了。

告警探测要从外部探测 HTTPS 握手拿到的真实证书有效期，而不是只读本地文件——部署没生效、证书挂在旧负载均衡器上这类问题，只有从外面看才暴露得出来。这就像检查烟雾报警器：按一下测试按钮不算数，得看它真遇烟响不响。

自动续签为主，但必须配失败兜底

手动续签不应该出现在规范里。人总会休假、换岗、忘事，把续签交给 ACME 协议（Let's Encrypt 等 CA 都支持，RFC 8555 定义了整套自动化流程）是规范的一部分，不是可选项。

但自动化不等于无人值守。规范里要写死一条：续签任务每次执行必须有结果记录，失败必须触发告警。很多人配了 cron 跑 certbot 就觉得万事大吉，结果某次 apt 升级把插件弄坏了，crontab 里安安静静地报错了两个月。

在 CertbotX 中实践这一条比较省事：它走 ACME 自动签发并在到期前重新签发，通配符域名可以用 DNS-01 CNAME 委托把验证域名指到专门的解析区域，不用把主 DNS 的 API 凭证散到各台机器上。续签后的证书能自动部署到 Agent、EdgeOne 或 CDN，部署动作留有记录，正好补上台账里"最后确认活着"那一栏，审计时也能说清某张证书是什么时候、被谁推到哪里的。

规范的边界：它不解决什么

写规范比写规范不做什么更难。这套做法的适用边界要说清楚：

• 内部 PKI 不适用：企业自签 CA、短证书（几小时有效期）场景需要另一套体系，比如服务网格里的自动 mTLS，硬套 ACME 流程会很别扭。
• OV/EV 证书续签有人工环节：涉及组织信息核验的证书没法全自动，规范里只能做到提前告警和预留窗口，不能承诺"无感续签"。
• 它防的是"忘了"，防不了"配错了"：证书链不完整、SNI 配置错位、HSTS preload 后证书覆盖不全，这些是配置问题，要靠上线检查清单而不是到期告警来兜底。
• 密钥安全是另一份规范：私钥的存储权限、轮换策略、泄露后的吊销流程，别和到期管理混在一起写，混在一起往往两边都没人看。

最后一条小坑提醒：规范落地后头一个月，大概率会收到一堆告警——那不是规范有问题，是以前欠的债浮出了水面。逐个清掉，之后告警才会回归"有事先响、响必是真事"的正常状态。

延伸阅读（用于核验文中涉及的协议与配置）：

• RFC 8555：ACME 自动证书管理协议 — 自动签发与续签的协议依据
• Let's Encrypt 官方文档 — 免费 CA 的签发速率限制与集成方式
• Nginx HTTPS 服务器配置 — 证书链与 SNI 的常见配置坑