4、实战案例：Nginx证书轮换故障、Kubernetes Ingress证书轮换故障、Java应用证书信任问题
理论讲完了，咱们直接上硬菜。这一章我挑了几个在生产环境里反复出现的证书轮换故障案例。说白了，都是我自己踩过的坑，或者帮别人擦过的屁股。你把这些案例吃透了，以后遇到类似问题，心里就有底了。
核心思路：证书轮换出问题，90% 的情况不是证书本身坏了，而是「加载时机」或「信任链」出了岔子。记住这句话，能省你半天排查时间。
4.1 Nginx 证书轮换：改了文件，但服务没生效
这是最常见的故障，没有之一。我记得有一次凌晨两点，业务方火急火燎地找我，说 HTTPS 访问报错，证书过期了。我登录一看，证书文件明明已经替换成新的了，但 Nginx 就是不走新证书。
为什么会这样？
Nginx 在启动或 reload 时，才会把证书文件读进内存。你只替换了磁盘上的文件，Nginx 进程手里拿的还是旧的那一把。我个人的习惯是，替换证书后，必须执行一次 nginx -s reload 或者 systemctl reload nginx。
但这里有个坑——reload 并不总是成功的。
避坑指南：我曾经遇到过一次，Nginx 配置里有个语法错误，reload 命令执行后，主进程没报错，但 worker 进程没加载新配置。结果就是，你以为轮换成功了，实际上用户还在用旧证书。所以，我建议你 reload 之后，一定要检查进程状态和错误日志。
正确的排查步骤：
- 检查证书文件：确认新证书的生效时间和序列号。
- 执行 reload：
nginx -s reload或systemctl reload nginx。 - 验证进程：
ps aux | grep nginx，看看 worker 进程的启动时间是不是最新的。 - 检查错误日志：
tail -f /var/log/nginx/error.log，看有没有配置加载失败的记录。 - 直接测试：用
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com查看返回的证书信息。
小技巧：我习惯写一个简单的脚本，把替换证书、reload、验证三步串起来。每次轮换，跑一遍脚本，省心又不会漏步骤。
4.2 Kubernetes Ingress 证书轮换：Secret 更新了，但 Ingress 没反应
K8s 环境下的证书轮换，比 Nginx 多了一层抽象。你更新了 Secret，但 Ingress Controller 不一定马上感知到。
我遇到过最诡异的一次：Secret 里的证书数据已经更新了，用 kubectl get secret 看也是对的，但访问服务还是提示证书错误。折腾了半天，发现是 Ingress Controller 的缓存机制在作怪。
核心问题：Ingress Controller（比如 Nginx Ingress、Traefik）会监听 Secret 的变化。但有些 Controller 的配置里，watch 间隔设置得比较长，或者有缓存策略。你更新了 Secret，它可能要等几分钟才去拉取。
排查清单：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 确认 Secret 已更新 | kubectl get secret my-tls -o yaml，检查 tls.crt 和 tls.key 的 base64 值是否为新证书。 |
| 2 | 检查 Ingress 引用 | kubectl get ingress my-ingress -o yaml，确认 spec.tls.secretName 指向的是正确的 Secret。 |
| 3 | 查看 Controller 日志 | kubectl logs -n ingress-nginx deployment/ingress-nginx-controller，搜索 "Secret" 或 "update" 关键词。 |
| 4 | 强制重启 Pod | 如果日志没有更新，可以尝试 kubectl rollout restart deployment/ingress-nginx-controller。 |
| 5 | 验证证书 | 用 openssl s_client 或浏览器访问服务，确认新证书已生效。 |
避坑指南：我曾经在 EKS 上遇到过一个坑，AWS Load Balancer Controller 管理的 Ingress，证书轮换后，ALB 监听器上的证书没有自动更新。最后发现是 Controller 版本太旧，不支持自动同步。升级版本后问题解决。所以，记得定期更新你的 Ingress Controller 版本。
4.3 Java 应用证书信任问题：证书明明有效，但程序就是报错
Java 应用的证书问题，是另一个重灾区。你明明在浏览器里访问是绿的，但 Java 程序一跑就报 PKIX path building failed。说白了，就是 Java 不认你的证书。
为什么？
Java 有自己的证书信任库（cacerts），它不信任操作系统里的根证书。你给 Nginx 配的证书，如果签发它的 CA 不在 Java 的信任库里，Java 就会拒绝连接。
我记得有一次，一个内部系统用了自签名证书。运维把证书配好了，Nginx 访问正常。但后端的 Java 服务调用这个系统时，一直报 SSL 握手失败。排查了半天，发现是 Java 的 cacerts 里没有导入自签名 CA 的根证书。
解决方案：
- 找到 Java 的 cacerts 文件：一般在
$JAVA_HOME/lib/security/cacerts。 - 导入根证书：
keytool -import -trustcacerts -alias my-ca -file /path/to/ca.crt -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit - 验证导入：
keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | grep my-ca - 重启 Java 应用：JVM 只在启动时加载信任库，所以必须重启。
小技巧：我建议你在 Java 应用的启动参数里加上 -Djavax.net.debug=ssl:handshake。这样，当 SSL 握手失败时，会打印详细的调试信息，告诉你具体是哪个证书不被信任。这个参数在排查时特别好用。
4.4 核心排查逻辑：一张图看懂
上面三个案例，其实都指向同一个排查逻辑。我画了张图，你一看就明白。
这张图的核心逻辑很简单：先确认证书文件本身没问题，再确认服务进程加载了新证书。对于 Java 应用，还要多走一步，检查信任库。你按这个顺序排查，基本不会漏掉什么。
总结一下：证书轮换故障，本质上就是「新证书没被用上」。要么是文件没放对，要么是进程没加载，要么是信任链断了。把这三个点盯死了，问题就解决了一大半。