事故回顾：一个 8443 端口拖垮了整条链路

事故回顾：一个 8443 端口拖垮了整条链路

某天凌晨，下游支付回调接口集中返回 SSL_ERROR_SYSCALL，上游风控服务重试 3 次后全部超时。排查 40 分钟后定位到原因极其简单——内部网关 gw-internal.example.com 的 TLS 证书在 UTC 时间 03:12 过期了，剩余有效期从告警窗口 30d 一路漏到了 0d，没有任何人收到通知。影响面：内网 6 个服务互相调用走 mTLS，全部中断约 50 分钟。

为什么没发现：三个经典盲区叠加

复盘后确认了三个同时存在的监控缺口：

• 证书生命周期完全脱离监控体系。证书用 cfssl 手动签发，放在 /etc/nginx/ssl/ 下，续期靠一条贴在 Wiki 里的 cron 备注。没有任何 exporter 在采集过期倒计时。
• 只监控了公网证书，忽略了内部 CA。团队用 prometheus/node_exporter 的 --collector.cert 或者 Blackbox 探针覆盖了 4 个域名，但内部自签 CA 签出的 12 张证书不在任何扫描列表里。
• 告警阈值设置不合理。唯一一条证书告警规则是 cert_expiry_days < 7，而那张过期证书的签发周期本身就只有 90 天，运维交接时已经只剩 5 天，规则触发过但被当作 flapping 丢弃了。

止血操作：从确认过期到恢复服务

恢复步骤按优先级做了以下动作：

• 在跳板机上执行 openssl s_client -connect gw-internal.example.com:8443 -servername gw-internal.example.com 2>/dev/null | openssl x509 -noout -enddate，确认 notAfter 字段已过去 14 小时。
• 用内部 cfssl 根 CA 重新签发 3 年期证书：cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -profile=internal gw.csr.json | cfssljson -bare gw。
• 替换 /etc/nginx/ssl/gw.crt 和 gw.key，执行 nginx -t && nginx -s reload，无需重启，连接池自动恢复。
• 同步更新 6 个下游服务中 ssl_trusted_certificate 指向的 CA bundle，防止 pinning 失效。

补上监控：从一次性修复到常态化

事故后一周内落地了三项改动：

• Blackbox 探针全量覆盖。在 Prometheus Blackbox Exporter 的 modules 里加了 tcp_connect 和 http_2xx，对 *.example.com 做泛域发现，probe_ssl_earliest_cert_expiry 指标直接暴露每张证书剩余秒数。
• 告警规则重写。阈值改为三级：<30d 为 warning（企业 IM 通知），<14d 为 critical（电话升级），<7d 为 page（同时通知 on-call 和 owner）。对 90 天短周期证书，warning 阈值自动按比例缩放为 0.3 × lifetime。
• 续期自动化。把 cfssl 签发和 Nginx reload 封装成 cert-rotate.sh，接入 Jenkins Pipeline，每周日 02:00 执行一次 --dry-run，到期前 21 天自动续期，人工只做审批。

延伸思考：证书只是冰山一角

证书过期之所以危险，是因为它同时具备三个特征：低频次触发（一年一两次）、静默退化（过期前一切正常）、爆炸半径大（所有依赖方同时受影响）。符合这三个特征的隐患还有：API Token 的 max_age 到期、内部 DNS 记录的 TTL 漂移、对象存储 Bucket 的 ACL 轮换遗漏。它们天然不会出现在业务指标的异常曲线里，只能靠专项巡检覆盖。把这类"不报警就永远不知道"的静默风险纳入监控清单，是这次事故最大的教训。