你遇到的这个问题确实挺棘手——服务器明明收到了ClientHello，但客户端就是不肯继续走Cipher Suite协商流程，最后直接超时断连。结合我处理这类SSL握手问题的经验，给你梳理几个核心排查方向：

1. 先确认两端Cipher Suite的交集 #

首先得从SSL调试日志里精准定位客户端和服务器各自支持的Cipher Suite列表：

• 服务器端：找日志里类似 ServerHello, Cipher Suite: 的条目，或者服务器启动时加载的Cipher Suite清单
• 客户端：在ClientHello对应的日志块里，找到以 Cipher Suites: 开头的内容

如果两端没有共同支持的Cipher Suite，客户端会直接终止协商，这是最常见的原因之一。注意别把TLS 1.3的Suite混进来，你用的是TLS 1.2，得盯着对应版本的Suite格式（比如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384这类）。

2. 双向认证的证书与信任链必须无漏洞 #

双向认证对两端的证书配置要求很高，任何一环出问题都可能导致握手中断：

• 客户端侧：检查truststore是否正确导入了服务器的根证书/中间证书，javax.net.ssl.trustStore和javax.net.ssl.trustStorePassword参数有没有配置错误
• 服务器侧：确认truststore里包含客户端证书的完整信任链，同时检查服务器是否开启了强制客户端认证（比如Tomcat里要设置clientAuth="required"）

另外还要核对证书的有效期、密钥用法——比如客户端证书必须允许digitalSignature和keyEncipherment，过期或用法不符合要求的证书会直接被客户端拒绝。

3. 排查JVM配置的冲突与版本限制 #

你提到的sun.security.ssl.allowUnsafeRenegotiation=true主要解决重协商问题，和初始握手的Cipher Suite协商关系不大。反而要重点关注这些：

• 不同JDK版本对TLS 1.2的支持有差异，比如JDK 7默认可能没启用部分强加密Suite，JDK 8之后才默认支持更多。可以尝试添加JVM参数强制锁定TLS 1.2并指定允许的Suite：

  -Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2 -Djavax.net.ssl.enabledProtocols=TLSv1.2
  -Djdk.tls.cipherSuites=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,...
  

• 检查是否有框架配置（比如Spring Boot）覆盖了JVM的SSL参数，确保客户端和服务器的配置逻辑一致。

4. 抓包看完整握手流程 #

如果调试日志信息不够，用Wireshark抓包过滤ssl协议，看完整的握手交互：

• 确认服务器是否依次发送了ServerHello、Certificate、CertificateRequest（双向认证必备）、ServerHelloDone这些包
• 如果服务器没发ServerHello，说明它不支持ClientHello里的任何Suite；如果发了但客户端没回应，大概率是客户端不信任服务器证书，或者自身证书有问题

5. 用简化场景缩小问题范围 #

先把场景简化，排除复杂业务代码的干扰：

• 用openssl s_client模拟客户端连接服务器，测试握手是否能成功：

  openssl s_client -connect your-server:port -tls1_2 -cert client-cert.pem -key client-key.pem -CAfile server-ca.pem
  

• 如果openssl能成功握手，问题大概率在你的Java客户端代码或配置上；如果openssl也失败，那就是服务器端的配置问题（比如Cipher Suite配置错误、客户端信任链缺失）

最后提个小技巧：SSL调试日志里，ClientHello之后如果看不到客户端发送ClientKeyExchange、CertificateVerify这些包，那几乎可以确定是客户端在收到ServerHello后发现了不可接受的情况——仔细找日志里的ERROR或fatal级别的提示，往往藏着关键原因。

内容的提问来源于stack exchange，提问作者Raul Valdoleiros