先说结论这类问题在 Azure Redis Cluster 上出现时日志里的那行javax.net.ssl.SSLHandshakeException会很有误导性表面看是证书异常实际根因往往不是“证书坏了”而是 Java 信任库里缺了 Azure 这套 TLS 证书链上的一环。我在预发环境被这个报错卡了大半天最后用keytool和openssl把服务器证书链和本地信任库逐层比对才定位到是根证书切换导致的信任链断裂。这篇就把整个排查链路、修复方案以及在 Redis Cluster 模式下容易踩的连环坑完整写下来。如果你正在用 Azure Redis或者 Java 客户端里即将撞上同款java.security.cert.CertificateException这篇文章值得读完再动手。1. 报错现场两种“同类不同根”的 CertificateException 必须先分清很多人在日志里看到CertificateException就直接去翻证书、换证书但同一个java.security.cert.CertificateException实际上可能对应两种完全不同的失败原因处理方式也完全相反。分不清这两个分支排查方向很容易跑偏。1.1 第一种信任链构建失败报错是 PKIX path building failed最常见的报错堆栈长这样javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.validator.PKIXValidator.doBuild(Unknown Source) Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target注意关键字unable to find valid certification path。它的含义是JSSE 拿到了 Azure Redis 服务器下发的 TLS 证书链但在本地信任库默认是 JDK 的cacerts里找不到任何一个可以衔接起来的根证书于是无法构建出“服务器证书 - 中间证书 - 根证书”的完整信任链。用一个生活化的类比你收到一个快递物流单上的每一级中转站都写清楚了但你手里没有最终收件人的电话系统无法确认这个包裹该交给谁于是整条配送路径直接判定无效。1.2 第二种主机名校验失败报错是 No subject alternative names matching另一种常见报错长这样java.security.cert.CertificateException: No subject alternative names matching IP address 20.101.135.5 found at java.base/sun.security.util.HostnameChecker.matchIP(Unknown Source)注意关键字No subject alternative names matching。它的含义是服务器下发的证书本身是受信任的信任链没问题但证书的 SANSubject Alternative Name主题备用名称扩展里写的域名或 IP 列表和你客户端代码里实际要连接的主机地址对不上。生活化类比这个人的身份证是真的也确实在公安系统里有记录但证件上的姓名和眼前这个人对不上门卫依然不能放行。1.3 动手之前先看第一个 cause 再决定方向我在这次排障中最重要的经验是不要急着改代码也不要急着导入证书先把报错堆栈的 first cause 抓出来看一眼。报错关键字根因方向后续修复抓手unable to find valid certification path本地信任库缺少对应根证书/中间证书导入正确的根证书到 cacerts 或应用级 TrustStoreNo subject alternative names matching IP address/domainTLS 握手成功但主机名校验失败对齐连接端点域名或在 Cluster 模式下合理关闭节点成员校验如果你的应用日志里既有unable to find valid certification path又同时有No subject alternative names那说明问题被叠了两层先把信任库补齐再处理主机名校验。不要指望一个开关同时解决两个问题。2. 为什么连 Azure Redis Cluster 会突然撞上证书问题理解了报错类型接下来要回答一个更关键的问题为什么之前运行得好好的应用某天突然开始报CertificateException要解释这点得先搞清楚 Azure Redis 的 TLS 证书体系是怎么组织的。2.1 Azure Redis 的 TLS 强制策略6380 端口与 rediss 协议Azure Redis 提供两个连接端口6379是非 TLS 端口6380是 TLS 端口。官方推荐客户端一律通过6380连接连接串用rediss://前缀。rediss://:你的访问密钥myredis.redis.cache.windows.net:6380在生产环境里Azure 侧甚至可以直接禁用非 TLS 端口强制客户端必须走 TLS。这就意味着你的 Java 应用只要在用 Azure Redis就永远要过 TLS 证书验证这一关。2.2 证书链三段式服务器证书、中间证书和根证书一个标准的 TLS 证书链通常由三部分组成服务器证书Leaf Certificate绑定具体的域名比如*.redis.cache.windows.net。中间证书Intermediate Certificate由 CA 签发给服务器证书。根证书Root CertificateCA 的根是整个信任链的锚点。Java 的默认信任库里装的是各家 CA 的根证书。TLS 握手时服务器一般会把 Leaf 证书和 Intermediate 证书主动下发下来但根证书通常不会下发客户端需要在自己本地信任库里找到能够衔接上的根证书。如果客户端找不到根证书或者服务器下发的中间证书在本地信任库里也无法补全JSSE 就会抛第一节里的PKIX path building failed。2.3 关键背景Azure 的根证书迁移让“昨天正常今天报错”这就是为什么很多团队会碰到“代码没改、配置没动、一夜之间全挂”的情况。Azure 在 2024 年对托管服务的 TLS 证书体系做了一次根证书迁移大量服务的证书从旧的Baltimore CyberTrust Root体系切换到由DigiCert Global Root G2签发。如果你的 JDK 的cacerts里只信任Baltimore CyberTrust Root却不认识DigiCert Global Root G2那么当 Azure 侧完成证书签发体系切换后你的 Java 客户端就会在 TLS 握手时直接报PKIX path building failed。这里有一个很隐蔽的坑JDK 的cacerts文件不会自动更新。即使你升级了应用代码只要 JVM 没换、cacerts没被修改这个问题就会一直存在。2.4 Cluster 模式的放大效应每个分片节点都要单独握手如果你的应用连的是 Azure Redis Cluster问题会被进一步放大。Cluster 模式下客户端首先连接配置的端点然后通过CLUSTER SLOTS命令拉取分片节点拓扑拿到每个主节点和副本节点的地址。接下来客户端会向这些节点分别建立 TLS 连接。也就是说非集群模式只需要成功握手一次Cluster 模式需要成功握手很多次。只要其中一个分片节点的证书验证失败整个集群操作就会失败而且往往表现为“间歇性”、“随机节点报错”因为拓扑刷新时会重新握手。从现象上看你可能感觉是“偶发连接超时”打开日志才发现真正原因一直是同一个CertificateException。3. 用 keytool 和 openssl 做一次完整的证书体检既然怀疑是证书链问题就不要再猜了。直接对着 Azure Redis 端点做一次“体检”把服务器下发的证书链抓出来再对比本地 JDK 的信任库答案会非常直观。下面是完整的操作链路。3.1 用 keytool 直接探测服务器证书链JDK 里有个很好用的命令可以绕过应用代码直接查看某个 TLS 端点的服务器证书链keytool -printcert -sslserver myredis.redis.cache.windows.net:6380执行后keytool会完成 TLS 握手并打印出服务器证书链上的所有证书包括 Subject、Issuer、有效期和 SHA256 指纹。输出里第一张是服务器证书第二张一般是中间证书以此类推。用这个命令你十秒钟就能确认两个关键信息服务器证书的 Issuer 是哪家 CA服务器证书链里有没有下发完整的中间证书。3.2 用 openssl s_client 抓取完整证书链并保存如果你想对证书链做更深入的分析或者需要把证书保存下来用openssl s_client是更好的选择openssl s_client -connect myredis.redis.cache.windows.net:6380 \ -servername myredis.redis.cache.windows.net -showcerts \ /dev/null 2/dev/null | tee /tmp/azure_redis_chain.pem这个命令会把完整的握手过程和证书链以 PEM 格式输出到/tmp/azure_redis_chain.pem。接下来按顺序提取每一张证书分别查看它们的 Subject 和 Issuerawk /-----BEGIN CERTIFICATE-----/{count} count1 /tmp/azure_redis_chain.pem | openssl x509 -noout -subject -issuer -dates awk /-----BEGIN CERTIFICATE-----/{count} count2 /tmp/azure_redis_chain.pem | openssl x509 -noout -subject -issuer -dates awk /-----BEGIN CERTIFICATE-----/{count} count3 /tmp/azure_redis_chain.pem | openssl x509 -noout -subject -issuer -dates在我遇到的这次问题里服务器下发的证书链结构是这样的第 1 张服务器证书Subject 是CN*.redis.cache.windows.net第 2 张中间证书Issuer 是CNMicrosoft Azure RSA TLS Issuing CA 04第 3 张根证书Issuer 是CNDigiCert Global Root G2如果你发现服务器实际没下发根证书很多服务器为了节省握手包大小确实不下发根证书那就需要客户端本地信任库里有对应的根证书。3.3 检查当前 JDK 的 cacerts 里有什么确认服务器证书链之后立刻检查本地 JDK 的cacertsKEYSTORE$JAVA_HOME/lib/security/cacerts keytool -list -keystore $KEYSTORE -storepass changeit | grep -i digicert这里有两个细节需要注意cacerts的默认密码是changeit如果你的生产环境修改过要用实际密码替代一台机器上可能装了多个 JDK必须确认应用实际使用的是哪一个。可以用java -XshowSettings:properties -version 21 | grep java.home来确认。如果 grep 之后没有输出说明本地 JDK 的信任库里根本没有 DigiCert 系列的根证书。3.4 排除“应用自定义 TrustStore 覆盖默认库”的隐蔽情况还有一种很容易被忽略的情况应用本身在启动参数或代码里自定义了javax.net.ssl.trustStore直接绕开了默认的cacerts。排查三步走看启动脚本、JAVA_TOOL_OPTIONS环境变量有没有-Djavax.net.ssl.trustStore检查application.yml或application.properties里有没有配置server.ssl.trust-store或spring.redis.ssl相关的内容检查应用代码里是否手动创建了SSLContext比如SSLContext sslContext SSLContext.getInstance(TLS); TrustManagerFactory tmf TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); KeyStore ks KeyStore.getInstance(JKS); ks.load(new FileInputStream(/opt/app/custom-truststore.jks), changeit.toCharArray()); tmf.init(ks); sslContext.init(null, tmf.getTrustManagers(), null);如果应用走了自定义 TrustStore那即使你改了全局cacerts也没有用因为代码里只认自定义的 KeyStore。4. 修复实操让 JDK 认识正确的根证书定位到根因之后修复本身并不复杂但有几个细节直接影响修复能否一次成功我这里按推荐程度从高到低给出三套方案。4.1 方案一把 DigiCert Global Root G2 导入 JDK 全局 cacerts这是我最推荐的生产环境修复方式因为它对应用无侵入只要改一次 JDK 的信任库所有跑在这个 JDK 上的 Java 应用都能生效。第一步从 DigiCert 官方根证书页面下载DigiCert Global Root G2的 PEM 格式证书文件保存为DigiCertGlobalRootG2.crt。第二步导入之前一定要核对证书信息keytool -printcert -file DigiCertGlobalRootG2.crt确认输出里的 Subject 是CNDigiCert Global Root G2并用 SHA256 指纹与官方渠道交叉验证。注意不要轻信网上任何人贴出的指纹包括我写的一定要到权威来源核对一遍。第三步导入到 JDK 的cacertskeytool -importcert -trustcacerts -noprompt -storepass changeit \ -alias digicertglobalrootg2 \ -keystore $JAVA_HOME/lib/security/cacerts \ -file DigiCertGlobalRootG2.crt如果cacerts文件属于 root 用户你需要sudo执行。JDK 9 以上也支持用-cacerts简写代替-keystore $JAVA_HOME/lib/security/cacertskeytool -importcert -trustcacerts -cacerts -storepass changeit -noprompt \ -alias digicertglobalrootg2 -file DigiCertGlobalRootG2.crt第四步验证导入结果keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | grep digicert看到digicertglobalrootg2这个别名就说明导入成功。然后重启应用重新跑一遍业务用例即可。这里补一个经验如果服务器下发的中间证书自身有问题或者本地信任库里恰好有同名的中间证书把根证书导入后依然有可能报错。遇到这种残留情况可以尝试把中间证书也一起导入keytool -importcert -trustcacerts -noprompt \ -alias azureredisintermediate \ -keystore $JAVA_HOME/lib/security/cacerts \ -file /tmp/azure_redis_intermediate.crt但大多数时候只要根证书到位JSSE 就能自己把路径拼出来。4.2 方案二独立的应用级 TrustStore最小化改动如果不想动全局cacerts或者你担心影响同 JVM 里的其他 TLS 调用可以用独立 TrustStore 方案。第一步创建只包含 DigiCert Global Root G2 的 JKS 文件keytool -importcert -noprompt -alias digicertg2 \ -file DigiCertGlobalRootG2.crt \ -keystore /opt/app/azure-redis-truststore.jks -storepass changeit第二步在启动参数里指向这个 TrustStorejava -Djavax.net.ssl.trustStore/opt/app/azure-redis-truststore.jks \ -Djavax.net.ssl.trustStorePasswordchangeit \ -jar app.jar或者设置环境变量export JAVA_TOOL_OPTIONS-Djavax.net.ssl.trustStore/opt/app/azure-redis-truststore.jks -Djavax.net.ssl.trustStorePasswordchangeit注意这样配置后JVM 内所有 TLS 出站连接都会使用这个 TrustStore。如果应用同时依赖默认cacerts里的其他根证书比如连数据库、调其他云 API就必须把那些根证书也一起导入这个 JKS否则会出现“修好了 Redis又断了别的服务”的新问题。4.3 方案三只针对 Redis 客户端做 SSLContext 配置如果你只想影响 Redis 客户端不想碰 JVM 级参数可以在代码层面给 Lettuce 或 Jedis 指定自定义的 SSLContext。以 Lettuce 为例SSLContext sslContext SSLContext.getInstance(TLS); TrustManagerFactory tmf TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); KeyStore ks KeyStore.getInstance(JKS); ks.load(new FileInputStream(/opt/app/azure-redis-truststore.jks), changeit.toCharArray()); tmf.init(ks); sslContext.init(null, tmf.getTrustManagers(), null); RedisURI uri RedisURI.builder() .withHost(myredis.redis.cache.windows.net) .withPort(6380) .withSsl(true) .withSslContext(sslContext) .withPassword(你的访问密钥) .build(); RedisClient client RedisClient.create(uri);Jedis 的构造器版本差异比较大但思路一样都是在创建JedisCluster时传入一个能正确加载 TrustStore 的SSLSocketFactory。4.4 强烈不建议信任所有证书的方案排查时间一长总有人提出“既然这么费劲干脆把证书校验直接关掉”的馊主意。网上也有一堆样例代码教你在X509TrustManager里直接返回true。我明确说这个做法只适合本地开发环境临时调试绝对不要上生产。信任所有证书的代价是你和 Azure 之间的数据加密形同虚设。任何能劫持网络流量的中间人都可以插入一台假服务器你无法察觉密码和业务数据等于明文裸奔。真到了上线阻塞的紧急关头宁可临时用 4.2 的独立 TrustStore 方案顶上也不要走这条路。5. Redis Cluster 模式下专属的证书连环坑如果你连的是 Azure Redis Cluster修完根证书可能还不够。Cluster 的拓扑机制会带来几个特有的问题我这次几乎一个不落全踩了。5.1 集群拓扑刷新与 TLS 重握手指向Redis Cluster 的客户端在启动时会先和配置的端点建立连接发送CLUSTER SLOTS拿到当前所有分片节点的 IP 和端口列表。之后客户端并不总是继续走你配置的那个域名而是会按拓扑结果去连接真实的节点地址。Azure Redis Cluster 返回的节点地址往往是 IP 而不是域名。当客户端直接拿着这个 IP 去建立 TLS 连接时服务器下发的证书里 SAN 写的是域名比如*.redis.cache.windows.net而不是这个 IP于是触发第一章说的第二种报错No subject alternative names matching IP address。5.2 Lettuce 的 validateClusterNodeMembership 配置Lettuce 提供了集群节点成员校验开关默认是true也就是会校验拓扑里的节点 host 是否与集群状态一致。在 Azure Redis Cluster 这种“证书绑域名、拓扑返回 IP”的场景下建议关闭ClusterTopologyRefreshOptions topologyRefreshOptions ClusterTopologyRefreshOptions.builder() .enablePeriodicRefresh(Duration.ofMinutes(1)) .enableAllAdaptiveRefreshTriggers() .build(); ClusterClientOptions clientOptions ClusterClientOptions.builder() .topologyRefreshOptions(topologyRefreshOptions) .validateClusterNodeMembership(false) .build(); RedisClusterClient clusterClient RedisClusterClient.create(uri); clusterClient.setOptions(clientOptions);关键就是.validateClusterNodeMembership(false)。关闭后客户端不会因为拓扑节点地址和证书 SAN 对不上而拒绝连接。5.3 Spring Data Redis Cluster 的 SSL 配置示例如果你用的是 Spring Boot Spring Data Redis可以这样配置spring: data: redis: cluster: nodes: - myredis.redis.cache.windows.net:6380 ssl: enabled: true注意版本差异Spring Boot 2.x 的配置项是spring.redis.ssltrueSpring Boot 3.x 换到了spring.data.redis.ssl.enabledtrue。如果你的application.yml里写错了前缀配置不会生效应用会走非 TLS 连接端口对不上时会出现另一类连接错误。如果还需要自定义 Lettuce 的ClusterClientOptions用 Java 配置类会更灵活Bean public RedisConnectionFactory redisConnectionFactory() { RedisClusterConfiguration clusterConfig new RedisClusterConfiguration( List.of(myredis.redis.cache.windows.net:6380) ); clusterConfig.setPassword(RedisPassword.of(你的访问密钥)); LettuceClientConfiguration clientConfig LettuceClientConfiguration.builder() .useSsl() .and() .clientOptions(ClusterClientOptions.builder() .validateClusterNodeMembership(false) .build()) .build(); return new LettuceConnectionFactory(clusterConfig, clientConfig); }5.4 MOVED 和 ASK 重定向时的 TLS 开销Cluster 的槽位迁移、数据分片调整会触发MOVED或ASK重定向。客户端收到这些响应后会去连接新的节点。每一次重定向都是一次新的 TLS 握手。如果某个节点的证书信任有问题重定向时就会再次触发CertificateException表现为“数据都正常但偶尔有一个 key 的操作失败报证书错”。这种间歇性问题最难排查因为低频、随机容易被当成偶发网络抖动。我的建议是在集群拓扑刷新配置里开启自适应刷新让客户端主动定期刷新拓扑减少因为槽位变化而被迫进行的高成本重连。上面的配置里用到的enableAllAdaptiveRefreshTriggers()就是干这个的。6. 验证、监控以及以后不再手忙脚乱修复做完不代表结束验证和长期维护同样重要。我把自己事后沉淀下来的一套方法放在这里。6.1 修复后的三步验证第一步用redis-cli确认服务器侧正常排除 Azure 侧问题redis-cli -h myredis.redis.cache.windows.net -p 6380 --tls \ -a 你的访问密钥 ping看到PONG说明服务器侧没问题。第二步写一个极简的 Java 类走 JDK 的默认 SSL 上下文直接和 Azure Redis 端点完成一次 TLS 握手检查证书链能否正常打印import javax.net.ssl.SSLSocket; import javax.net.ssl.SSLSocketFactory; import java.security.cert.Certificate; public class TestAzureRedisTLS { public static void main(String[] args) throws Exception { String host args[0]; int port Integer.parseInt(args[1]); SSLSocketFactory factory (SSLSocketFactory) SSLSocketFactory.getDefault(); try (SSLSocket socket (SSLSocket) factory.createSocket(host, port)) { socket.setSoTimeout(10000); socket.startHandshake(); System.out.println(TLS握手成功协议: socket.getSession().getProtocol()); int i 1; for (Certificate cert : socket.getSession().getPeerCertificates()) { System.out.println(证书[ i ]: cert); i; } } catch (Exception e) { System.out.println(TLS握手失败: e.getMessage()); e.printStackTrace(); } } }编译运行javac TestAzureRedisTLS.java java TestAzureRedisTLS myredis.redis.cache.windows.net 6380握手成功并打印出证书链说明 JVM 级的信任库已经没有问题。第三步启动应用跑一遍完整业务链路在日志里搜SSLHandshakeException和CertificateException确认不再出现。6.2 证书有效期监控Azure 侧会主动轮换服务器证书但不会替你做客户端信任库的升级。我建议写一个简单的监控脚本定期检查 Azure Redis 端点证书的到期时间echo | openssl s_client -connect myredis.redis.cache.windows.net:6380 \ -servername myredis.redis.cache.windows.net 2/dev/null | \ openssl x509 -noout -dates把输出里的notAfter时间接入现有告警体系提前 30 天提醒避免证书轮换后整个集群突然“失联”。6.3 容器化场景下不把证书导入 Dockerfile 会白改如果你的 Java 应用是容器化部署只改本地开发机的cacerts完全没用。容器镜像重建后cacerts会恢复成镜像里的原样。正确做法是把证书导入写进 DockerfileFROM eclipse-temurin:17-jre COPY certs/DigiCertGlobalRootG2.crt /tmp/DigiCertGlobalRootG2.crt RUN keytool -importcert -trustcacerts -cacerts -storepass changeit -noprompt \ -alias digicertglobalrootg2 -file /tmp/DigiCertGlobalRootG2.crt \ rm -f /tmp/DigiCertGlobalRootG2.crt注意不同基础镜像的 JDK 路径不同。比如eclipse-temurin的JAVA_HOME是/opt/java/openjdk而某些基于debian的镜像可能装在/usr/lib/jvm/下。确认路径后也可以在 Dockerfile 里加一个构建期自检RUN keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | grep digicert这样只要镜像里没有正确的根证书构建就会直接失败而不是到了运行期才报错。6.4 把证书检查写进团队上线 checklist最后一件真正能减少团队踩坑的事把这套检查固化为上线 Checklist 的一部分。我现在的习惯是任何涉及 Azure Redis 的 Java 服务上线前至少确认三件事JDK 信任库里是否有 Azure Redis 当前证书链对应的根证书连接串是否显式使用了rediss://和6380端口若走 Cluster 模式Lettuce/Jedis 的节点成员校验配置是否符合 Azure 的“域名证书 IP 拓扑”特性。有了这个流程后续再遇到类似的证书问题直接按流程走一遍就能定位不用再从零开始翻日志。这次排障后我把上述经验都固化到了团队文档里尤其是那句“先看 first causeunable to find valid certification path和No subject alternative names是两个完全不同的方向”写在了文档第一行。最后再分享一个小技巧以后怀疑任何 Java 连不上 TLS 端点的问题先别急着翻日志直接用keytool -printcert -sslserver打一下对方的证书链十秒就能判断是信任链问题还是主机名校验问题比在日志里反复找 cause 高效得多。