ClientKeyExchange未在ServerHelloDone后执行，JDK6环境REST连接异常排查

我之前碰到过类似的JDK 6下TLS握手卡壳的情况，结合你描述的细节，给你几个实用的排查和解决方向：

• 先搞懂「硬件加密设备」的影响：
  其实这里说的硬件加密设备，就是你笔记本自带的加密相关硬件——比如部分机型带的TPM安全芯片、集成了加密加速模块的网卡，或者某些厂商的专属安全组件。JDK 6会默认尝试调用这些硬件来处理TLS握手里的密钥生成/交换操作（也就是ClientKeyExchange步骤要做的事），如果你的故障机器硬件不在JDK 6的支持列表里，或者硬件驱动有问题，就会导致这一步直接卡住，没法继续握手。

• 强制禁用硬件加密，改用软件加密：
  既然两台机器的密码套件完全一致，那可以先绕开硬件加密试试，强制JDK用纯软件实现加密：

  • 临时测试：启动应用时添加这两个JVM参数：

    -Djava.security.egd=file:/dev/./urandom -Dsun.security.ec.disableNative=true
    

    前者是指定用软件随机数生成器，后者是禁用椭圆曲线算法的硬件加速；如果是其他加密算法的问题，还可以尝试添加 -Dcom.sun.net.ssl.enableECC=false。
  • 永久配置：修改故障机器JDK安装目录下的 jre/lib/security/java.security 文件，找到以 security.provider.N 开头的配置行，把涉及硬件加密的Provider（比如SunPKCS11、IBMJCE这类）注释掉，或者移到列表的最后，让纯软件的SunJCE排在最前面，优先被调用。

• 检查系统底层加密库的差异：
  JDK 6的TLS实现会依赖系统底层的加密组件（比如Windows上的Schannel服务，Linux上的OpenSSL库），哪怕JDK版本完全一致，系统的加密组件版本、补丁情况不同也会导致握手失败。你可以：

  • Windows机器：检查系统是否安装了最新的TLS相关补丁，确保Schannel服务正常运行；
  • Linux机器：对比两台机器的OpenSSL版本，确保依赖的加密库版本一致。

• 尝试替换证书库：
  虽然你说两台都用默认的cacerts，但有时候证书库的细微差异（比如某些根证书的信任状态）也会间接影响握手流程。可以把正常机器上的 jre/lib/security/cacerts 文件复制到故障机器上替换原文件（记得先备份），然后重启应用测试。

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