事故背景：一次凌晨的证书过期告警

事故背景：一次凌晨的证书过期告警

周三凌晨 2 点，值班同事收到一条来自业务方的截图：某 API 网关返回 SSL_ERROR_EXPIRED_CERT，iOS 客户端批量提示「网络连接失败」。我们用 openssl s_client -connect api.example.com:443 -servername api.example.com | openssl x509 -noout -dates 确认证书已于当天 0 点过期ulant。事后复盘发现：证书由外网 CDN 回源链路上的一个二级域名持有，到期前 30 天内部并未收到任何提醒。真正的问题不是「忘了续期」，而是整个监控体系里没有任何一个探针覆盖这个域名。

为什么现有监控没覆盖到它

翻看监控大盘，问题清晰得有点刺眼：

• Zabbix 上对证书 notAfter 的检查，模板只挂在了 3 台 Nginx 的 443 端口，通过 openssl x509 -enddate 取值算剩余天数，告警阈值 15 天；
• 那台二级域名用的是云厂商 CDN 的证书，到期前 30 天自动签发新证书，但我们开启的是「手动上传」模式，控制台不会推送续签通知，这条路径完全不在监控里；
• Prometheus 里的 blackbox_exporter 只做了 TCP 和 HTTP 探活，prober: http 没开 tls 的证书指标采集，健康检查 200 就绿灯；
• 证书台账是一张 Excel，挂在运维组共享盘，最后一次更新是半年前。

四条路径各管一段，但对「每个对外的 TLS 端点」没有任何一个全局视角去保证覆盖率，这才是真正的盲区。

即时处置与止血流程

凌晨的处置不宜重构，先止血再补。

• 第一步，登录云 CDN 控制台，找到该域名的证书配置，把刚续签好但未绑定的新证书手动推上去，证书 ID 核对一遍，SHA-256 指纹与域名 SAN 一一对应；
• 第二步，切到备用线路，检查回源失败率，确认 5 分钟内客户端错误率从 30% 回落到基线；
• 第三步，写临时告警：curl -sv --servername api.example.com https://api.example.com:443 2>&1 | openssl x509 -noout -enddate 结果大于 3 天，相关人收到通知；
• 最后，把完整时间线、影响面、处置动作同步到事故群，不急着开复盘。

复盘：从「单点检查」到「端点台账」

复盘的核心结论是：证书监控不要按机器挂，而要按「对外可达的 TLS 端点」挂。补做的改造有三层：

• 用 curl -v https://your-endpoint 2>&1 | grep -i 'expire date' 或 openssl s_client 批量扫一遍全量域名、负载均衡、CDN、内网 TLS 服务，建立一份端点清单，标注探针方式（外部真实探针 / 内网探针）；
• 用 blackbox_exporter 的 tls_config probe，配合 probe_ssl_earliest_cert_expiry 指标，把剩余有效期换算成天数接入告警，业务证书 30 天、内部服务 15 天两条阈值；
• 把云 CDN、证书托管平台的证书列表加进扫描任务，并规定证书续期走「自动续签 + 人工抽查」双轨，新增域名上线必须同时在台账和探针里登记，缺一不可。

把证书监控真正长期跑起来

改造上线后我们做了三件小事，确保盲区不会重新长出：

• 每周跑一次全量证书巡检，把 openssl s_client 采集的到期天数写进周报，超过 60 天的证书不报，30~60 天的列入待办，30 天内的钉钉告警；
• 证书清单与云资源清单做自动比对，发现没有探针覆盖的新域名时，直接触发告警，避免「加了一个域名没人管」；
• 把「证书到期」写进 SLO 和变更流程，续期和上线一样要走审批与验证记录，冷门的二级域名也纳入同一条流水线。

证书过期这类问题的根因往往不在技术，而在监控覆盖面被新接入路径一层层蚕食，直到所有路径都没有人负责。补一个探针只值两分钟，维护一份「所有对外的 TLS 端点都在测」的清单才是长期价值。