HTTPS 证书故障看起来简单，但在 CDN、负载均衡、Ingress 和源站并存的架构里，真正过期的证书不一定在你最先检查的位置。本文整理一套可以直接用于生产环境的排查和治理方法。
一、典型现象
浏览器提示“连接不安全”或
NET::ERR_CERT_DATE_INVALID。API 客户端、Webhook、监控探针突然出现 TLS 握手失败。
部分用户正常、部分用户异常，或者域名主站正常而某个子域名失败。
服务端应用没有明显报错，但网关或客户端大量出现 495、496、502。
先确认故障影响范围：是单个域名、单个入口、某一地区，还是所有 HTTPS 流量。不要只依赖浏览器缓存中的证书信息。
二、快速确认当前证书
curl -vkI https://example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -dates -issuer -subject -serial重点查看：
notAfter是否已经过期或即将到期；证书的 SAN 是否包含当前访问域名；
颁发者和序列号是否为预期版本；
完整证书链是否缺少中间证书；
SNI 指定后返回的证书是否发生变化。
若前面有 CDN、WAF 或负载均衡，还要分别检查公网入口和源站。可以使用 --resolve 绕过 DNS，验证指定 IP：
curl -vkI --resolve example.com:443:10.0.0.10 https://example.com三、常见根因
自动续期任务执行失败，但没有告警。
新证书已签发，却没有正确部署或重载 Nginx。
证书只更新了源站，CDN、Ingress 或负载均衡仍使用旧证书。
DNS 切换后，新入口没有同步证书。
服务器时间漂移，导致证书被误判为未生效或已过期。
续期账号权限、DNS API Token 或 HTTP-01 验证路径失效。
四、应急恢复
先备份当前证书和配置，再部署正确的新证书，检查配置后平滑重载：
nginx -t && systemctl reload nginx如果使用 Kubernetes，确认 Secret 已更新，并检查 Ingress Controller 是否已经加载新证书。不要为了恢复而关闭 HTTPS 校验，也不要长期使用临时自签名证书。
更新后从多个网络再次验证证书序列号、有效期和完整链路。若有 CDN，还应执行缓存刷新或证书重新绑定。
五、长期治理
在证书剩余 30、15、7、3、1 天时分级告警。
对外域名建立统一资产清单，记录域名、入口、证书位置和责任人。
自动续期后执行部署、重载和外部探测，不能只检查“签发成功”。
定期执行续期演练，例如
certbot renew --dry-run。监控证书链、域名匹配、OCSP 和 TLS 协议，而不只是到期时间。
变更 CDN、WAF、Ingress 或 DNS 时，把证书检查加入发布清单。
证书故障的核心不是“忘记续费”，而是证书资产缺少端到端管理。真正可靠的方案应覆盖发现、续期、部署、验证和告警整个闭环。