Java 11 HttpClient请求HTTPS站点报handshake_failure的问题咨询

精准定位故障根源 #

不要盲目调整代码或配置，先通过JSSE调试日志锁定具体不匹配的环节：

• 启动程序时追加JVM参数 -Djavax.net.debug=ssl:handshake:verbose，日志会完整输出TLS握手全流程交互：包括客户端ClientHello中携带的支持TLS版本、加密套件列表、可选椭圆曲线，以及服务端返回握手失败的具体触发原因。
• 重点核对三类匹配结果：
  • 客户端与服务端是否存在共同支持的TLS协议版本
  • 双方是否存在共同支持的加密算法套件
  • 双方是否存在共同支持的椭圆曲线组

绝大多数同类故障属于配置层面的算法协商不匹配，跳过调试日志直接修改代码基本无法解决问题。

当前运行环境（OpenJDK 11.0.11 on Ubuntu 20.04）高频故障点排查 #

这个版本的Ubuntu打包OpenJDK存在多个常见的TLS默认配置偏差，是导致维基百科这类站点握手失败的核心诱因——为什么同代码请求Google正常？因为Google的站点TLS协商兼容性做了非常宽松的适配，即使客户端携带的套件版本偏老也能完成协商，而维基百科当前使用的CDN节点已经淘汰了一批老的加密配置，刚好会触发本地JDK的默认配置不匹配问题：

• 该版本JDK的全局安全策略文件（路径为$JAVA_HOME/conf/security/java.security）中，jdk.tls.disabledAlgorithms配置项默认禁用了多个主流站点当前强制要求的算法，包括TLS1.3标配的TLS_AES_128_GCM_SHA256、ECDSA签名的TLS1.2套件、secp256r1椭圆曲线；jdk.tls.namedGroups配置项可能缺失主流曲线配置，导致服务端无法匹配到可用的椭圆曲线直接终止握手。检查上述两个配置项，把被错误禁用的主流算法从禁用列表移除，把缺失的椭圆曲线加入可用列表即可。
• 该版本内置HttpClient存在已知协商bug：默认构造的实例没有正确加载本地安全策略允许的TLS1.2/1.3套件列表，需要手动指定SSL上下文与协议版本，对应调整代码示例：

  SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
  sslContext.init(null, null, null);
  HttpClient client = HttpClient.newBuilder()
    .sslContext(sslContext)
    .version(HttpClient.Version.HTTP_2)
    .build();
  

• 关闭证书校验对该类错误完全无效：handshake_failure错误发生在算法协商阶段，流程还未进入证书校验环节，这类操作无法解决问题。

兜底修复方案 #

• 优先升级JDK小版本：当前使用的11.0.11是2021年发布的旧版本，11.0.16及后续小版本已经修复了绝大多数TLS默认配置问题，升级后同类握手故障通常会直接消失。
• 升级存在限制时，可通过JVM启动参数覆盖全局安全策略，绕过旧版本中错误的算法禁用配置。

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