Java 8（1.8_171）TLSv1.2 SSL握手失败问题求助

两台运行Redhat 7的服务器，均部署Java 1.8_171版本的相同应用，其中一台调用外部API正常，另一台出现SSL握手失败。通过对比Java SSL日志发现，异常服务器的ClientHello中缺失ECDHE/ECDH类密码套件，且未携带elliptic_curves和ec_point_formats扩展，导致服务器无法协商出兼容的加密套件，返回handshake_failure。

关键日志差异对比 #

正常服务器ClientHello核心内容 #

Cipher Suites: [...包含TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384等ECDHE/ECDH系列套件...]
Extension elliptic_curves, curve names: {secp256r1, secp384r1,...}
Extension ec_point_formats, formats: [uncompressed]

服务器最终协商使用TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384套件，握手成功。

异常服务器ClientHello核心内容 #

Cipher Suites: [仅包含RSA/DHE系列套件，无ECDHE/ECDH相关]
[无elliptic_curves和ec_point_formats扩展]

服务器无匹配套件，返回致命握手失败告警。

解决建议 #

1. 检查JCE无限制强度策略文件 #

Java 8u161及以后默认启用无限制加密策略，但部分Redhat分发的JDK可能仍使用受限策略：

• 进入$JAVA_HOME/jre/lib/security目录，查看local_policy.jar和US_export_policy.jar的版本。
• 若为受限版本，替换为对应JDK版本的无限制策略文件（可通过Redhat官方包java-1.8.0-openjdk-headless获取）。

2. 修正Java安全配置文件 #

编辑$JAVA_HOME/jre/lib/security/java.security：

• 查找jdk.tls.disabledAlgorithms配置项，确保未包含EC、ECDHE、secp256r1等关键字，若有则移除。
• 检查jdk.certpath.disabledAlgorithms，确保未限制EC类算法。
• 修改后重启应用生效。

3. 强制指定SSL密码套件 #

在应用启动参数中添加以下系统属性，强制包含正常服务器使用的ECDHE套件：

-Dhttps.cipherSuites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,[其他正常机中的ECDHE/ECDH套件]

可直接从正常服务器的ClientHello日志中复制完整的Cipher Suites列表。

4. 调整Redhat系统加密策略 #

Redhat 7的crypto-policies可能限制了椭圆曲线或TLS套件：

• 执行update-crypto-policies --show查看当前策略。
• 若为FUTURE或STRICT，可临时切换为DEFAULT策略：

  update-crypto-policies --set DEFAULT
  

• 切换后重启服务器或应用生效。

5. 验证Java版本与组件一致性 #

• 执行java -version确认两台服务器的JDK发行版（Oracle JDK/OpenJDK）及补丁完全一致。
• 检查$JAVA_HOME/jre/lib/ext/下的加密提供者jar包（如sunjce_provider.jar）版本是否相同，若不同则替换为一致版本。

6. 排查应用自定义SSL配置 #

若应用代码中自定义了SSLContext或SSLSocketFactory：

• 确保未手动过滤ECDHE系列套件，优先使用默认SSL上下文。
• 若需自定义，显式添加ECDHE相关套件到密码套件列表中。

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