SSL 证书过期排查实战：openssl + Nginx 4步从发现到续签
**摘要：**网站打不开不是宕机，是证书到期。本文用一次支付网关事故复盘，从 openssl 一行命令确认过期，到 Nginx TLS 配置排错，再到监控脚本与自动续签，给出一条完整的 4 步止血+根治路径。文末附分级告警阈值表，可直接照搬。
一、先定位：别一上来就重启
事故当晚 23:58，支付网关开始返回 TLS 握手失败，商户流水断崖式掉单。值班的兄弟本能反应是重启服务------这跟证书过期没关系，方向全错。证书过期是红锁，不是进程退出，所以重启、加机器、改配置全都没用。
我的习惯是：先定位层，再动手 。证书是网络层第一道关，浏览器一红锁、curl 一报 certificate has expired，方向就锁死了一半。
二、Step1：openssl 一行确认到期
确认证书到期的上策是终端一行命令，登录证书后台反而绕：
openssl s_client -connect 域名:443 \
-servername 域名 < /dev/null 2>/dev/null \
| openssl x509 -noout -dates输出会告诉你 notBefore 和 notAfter，关注 notAfter 这行。如果当前时间已经超过它，证书就是过期了。3 秒钟出结论。
三、Step2：Nginx TLS 配置排错
确认过期后，第二步是看 Nginx 是不是把新证书加载上了。很多人续签完忘了 nginx -s reload，或者 ssl_certificate 路径写错，Nginx 还在读旧证书，过期就发生在你眼皮底下。
4 个高频出问题的配置项：
ssl_certificate：路径写错就读不到新证书ssl_certificate_key：与证书要成对，否则握手失败ssl_protocols：别留 TLSv1.0/1.1，老协议隐患大ssl_session_timeout：长连接调长，省握手
四、Step3：监控是否漏接
排完配置，第三步要回答一个关键问题：为什么监控没告警？ 99% 的证书过期事故，根因不是没续签，是没接监控或监控阈值太松。
建议分级告警（提前量递减）：
| 剩余天数 | 级别 | 动作 |
|---|---|---|
| 30 天 | 黄 | 工单系统自动建单，提醒续签 |
| 15 天 | 橙 | 企微推值班群+抄送主管 |
| 7 天 | 红 | 电话值班人确认排期 |
| 1 天 | 紧急 | 主管+运维负责人同时告警 |
| 0 天 | 已过期 | 立即续签并人工验证 |
这阵子 AI退更潮 刷屏，一堆套模板的号说停就停。证书管理这种慢病也一样，平时看着没事，一遇事全抓瞎。我们当时盯着监控那条"0天"的告警愣了几秒，太安静了，监控真没接。
五、Step4：闭环从告警到工单到派单
光有告警不够，告警要闭环 ：告警 → 工单 → 派单 → 值班接单 → 续签 → 关单。否则告警淹没在群里，含金量 为零。
闭环的实现路径：监控脚本每日扫证书（certbot certificates 或 openssl -checkend），剩余天数命中阈值就推 WebHook 到工单系统，工单系统自动建单 + 派给值班人 + 抄送主管，值班人续签完成后在工单里贴 reload 截图关闭。
六、根因之外：为什么人会忘
讲真的，证书过期不是技术难题，是管理难题。讲真的，很多人买了贵证书、放进了日历、设了手机提醒，到了那天还是忘------因为"提醒"和"动作"之间缺一环。
当然也有人不这么想，觉得把证书交给云厂商自动续签就万事大吉。我偏不这么想，云厂商的自动续签只解决"续"这一段，不解决"告警到派单"的闭环。真正让系统反脆弱的，是告警自动建单、值班闭环、处置沉淀成预案。
我们这次事故后，把证书监控接进了工单系统，提前 30/15/7/1 天分级告警，自动派给值班人。半年没再出过同类问题。
七、给正在排障的你
如果你今天也在排查证书过期，按这 4 步走：
- 终端 openssl 确认是不是真的过期（别只信浏览器红锁）
- 查 Nginx 配置 + reload 状态（确认新证书有没有被加载）
- 看监控是否漏接、阈值是否合理（避免下次再漏）
- 把告警接进工单系统做闭环（让告警真的有人接）
主题：SSL/TLS 证书过期 · 故障系列 7 期（继磁盘满/MySQL连接数/Redis连接池/OOM/磁盘IO/CPU飙升 之后）。
关键词：中小企业工单系统哪家好用 / SaaS工单系统哪家性价比高。
热词：AI 退更潮 · 反脆弱 · 含金量。
排查经验请结合自身场景取舍，命令以本机 openssl / nginx 版本为准。