HTTPS 证书过期导致线上故障：一次完整的应急响应与复盘

故障背景

凌晨 2 点 17 分，值班手机骤然响起。监控平台推送了一条 P0 级告警：核心 API 网关的 HTTPS 握手失败率在 3 分钟内从 0.02% 飙升至 87%。紧接着，客服群、运维群、研发群几乎同时炸开——大量用户反馈 App 无法登录、H5 页面白屏、小程序请求全部超时。

这不是一次普通的服务抖动。从监控大盘来看，后端服务的 CPU、内存、QPS 全部正常，数据库连接池稳定，没有任何慢查询。问题出在流量入口：客户端与网关之间的 TLS 握手环节。进一步查看网关日志，大量 x509: certificate has expired or is not yet valid 错误赫然在目。

根因初步判断：HTTPS 证书过期。

应急响应过程

第一阶段：确认与止损（2:17 – 2:35）

值班 SRE 第一时间拉起了应急群，按照“先止损、后定位”的原则，迅速执行了以下操作：

1. 确认证书状态：通过 openssl s_client -connect api.example.com:443 -servername api.example.com 连接线上网关，输出中明确显示 Verify return code: 10 (certificate has expired)，证书有效期截止到前一天 23:59:59。
2. 切换备用证书：运维团队此前在负载均衡器上预置了一张通配符证书作为灾备，立即将其绑定到 HTTPS 监听器。但该证书仅覆盖 *.example.com，而部分业务使用了独立域名，导致约 30% 的流量仍然不可用。
3. 紧急申请新证书：联系证书供应商走加急签发流程，同时启用 Let's Encrypt 作为临时替代方案，为未覆盖的域名签发 90 天有效期的免费证书。

第二阶段：全面恢复（2:35 – 3:20）

• 2:48，Let's Encrypt 证书签发完成，通过自动化脚本分发到所有边缘节点。
• 2:55，网关逐步重启，TLS 握手成功率回升至 60%。
• 3:05，独立域名证书全部替换完毕，握手成功率恢复至 99.5%。
• 3:20，所有核心业务指标恢复正常，告警清除。

第三阶段：善后与验证（3:20 – 4:00）

• 对全站所有域名进行证书有效期扫描，确认无其他即将过期的证书。
• 回滚了故障期间产生的异常日志和缓存脏数据。
• 向客服同步了故障原因和恢复情况，准备了用户安抚话术。

根因分析

故障直接原因清晰：API 网关使用的 HTTPS 证书在夜间过期，而证书续期流程未能自动执行。

但深入复盘后，我们发现了更深层的系统性问题：

1. 证书管理分散：公司共有 47 张 HTTPS 证书，分布在不同的云账号、负载均衡器、CDN 和自建 Nginx 上，没有统一的资产台账。
2. 续期依赖人工：虽然部分证书使用了 ACME 协议自动续期，但核心网关的证书是早期手动申请的，续期提醒仅靠一张 Excel 表格和某位运维同学的日历备忘。
3. 缺乏监控覆盖：现有的拨测系统只检查 HTTP 状态码和响应时间，没有对证书有效期做专项监控。证书过期前 30 天、7 天、1 天均无任何告警。
4. 变更流程缺失：证书更换涉及网关配置变更，但该变更未纳入变更管理平台，没有审批和回滚预案。
5. 灾备方案不完整：备用证书的域名覆盖范围不足，且未定期验证其可用性。

改进措施

针对上述根因，我们制定了以下改进项，并明确了责任人和完成时限：

1. 建立证书统一管理平台

• 将所有 HTTPS 证书纳入 CMDB，记录域名、颁发机构、有效期、部署位置、负责人。
• 对接 ACME 协议，实现 90% 以上证书的自动续期和自动分发。
• 对于无法自动续期的商业证书，设置工单流程，提前 45 天触发采购和更换。

2. 完善监控与告警

• 在拨测系统中增加证书有效期检查，对全站域名每日扫描。
• 设置多级告警阈值：剩余 30 天提醒、剩余 7 天警告、剩余 1 天严重告警并电话通知。
• 将证书过期纳入业务连续性监控大盘，与核心业务指标同屏展示。

3. 优化应急响应预案

• 编写《HTTPS 证书过期应急操作手册》，明确切换备用证书、申请临时证书、回滚配置的具体步骤。
• 每季度进行一次证书过期模拟演练，确保值班人员熟悉流程。
• 备用证书必须覆盖所有生产域名，并每半年验证一次。

4. 推动变更规范化

• 所有证书更换操作必须通过变更管理平台提交，包含影响范围、回滚方案和验证步骤。
• 变更窗口尽量安排在业务低峰期，并提前通知相关方。

5. 引入混沌工程

• 在测试环境定期模拟证书过期、证书链不完整等场景，验证系统的容错能力和监控有效性。

经验总结

这次故障虽然只持续了约 1 小时，但影响面广、用户感知强烈，暴露出我们在基础安全设施管理上的短板。以下几点值得所有技术团队引以为戒：

• 证书是有生命周期的代码：它和应用程序一样需要版本管理、自动化部署和过期监控，不能依赖人工记忆。
• 监控要覆盖“非功能”指标：状态码和延迟之外，证书有效期、DNS 记录、域名注册时间等“冷门”指标同样致命。
• 灾备方案必须完整且经过验证：备用证书域名不全，等于没有备用。
• 自动化是可靠性的基石：任何需要人工重复操作的事情，最终都会在某个深夜出错。

故障发生后的一周内，我们完成了全部 47 张证书的盘点，其中 12 张转为自动续期，35 张设置了多级告警。证书管理平台也已进入开发排期。希望这次教训能成为团队基础设施治理的一个转折点——毕竟，HTTPS 证书过期这种“低级”故障，不应该再发生第二次。

未经允许不得转载：任鹏个人博客 » HTTPS 证书过期导致线上故障：一次完整的应急响应与复盘