一次 TLS 证书过期导致的服务故障排查记录
概要 某云服务器上的加密代理服务，在运行稳定数月后，于某日突然出现所有客户端无法连接的情况。网站访问正常，但加密代理完全失效。本文记录了从初步检测到最终定位问题的全过程。 一、问题现象 在问题出现前，所有客户端均能正常连接。某日夜间起，连接全部失败，日志中出现大量类似以下信息： 此错误表明 TLS 握手阶段证书验证失败，但当时并不清楚是客户端、服务端、还是中间环节的问题。 二、初步判断：排除外部因素 首先确认网络层和基础设施： 故障范围仅限于代理服务端口，指向服务自身配置问题。 三、证书与握手检测 通过 openssl s_client 对两个服务端口进行 TLS 测试。 网站端口（正常服务）： 代理端口（故障服务）： 对比结果表明： 即同一主机上存在两份不同的证书链，代理服务仍在使用旧版。 四、定位原因 进一步检查配置文件，代理服务的 TLS 设置如下： 路径正确，指向 live 目录的符号链接；但查看系统日志后发现，该进程已连续运行超过一周，而新证书的签发时间正是数天前。 说明该进程在新证书生成后从未重启过。由于此类服务不会自动重新加载证书文件，进程一直在使用内存中的旧证书。直到旧证书过期后，客户端才全部无法建立 TLS 握手。 五、解决与验证 重启服务后，再次检测： 握手恢复正常，客户端均可重新连接。 为防止同类问题再次发生，添加了自动重载机制。 六、预防措施 1. 在 Certbot 续期后自动重启相关服务 在 /etc/letsencrypt/renewal-hooks/deploy/ 下创建脚本： 每次证书续期成功后将自动重启代理服务。 2. 或使用 systemd.path 监控证书文件变化 当证书文件更新时自动触发 systemctl …