登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  java教程

JDK 26.0.2 HttpClient TLS 参数为什么终于生效:named groups 与签名方案边界

来源:17golang原创

时间:2026-09-03 18:09:03 174浏览 收藏

如果 Java 服务已经给 SSLParameters 设置了 named groupssignature schemes,但抓到的 TLS 协商结果完全没变化,先别急着怀疑数组名称。JDK 26.0.2 修复了一个更靠前的问题:旧版 HttpClient 会保存这些配置,却没有在新连接的 TLS 握手中使用它们。

升级到 JDK 26.0.2 及后续版本后,HttpClient 才会把 SSLParameters 中这两组有序列表带入新连接的 TLS 协商;但最终能否连接,仍取决于 TLS 提供者和服务端的共同支持。

要点速览
  • 修复范围是 HttpClient 新连接的 TLS 握手,不是所有 SSLParameters 行为。
  • 非空列表按优先级参与协商,null 使用提供者默认值,空数组会关闭对应机制。
  • SunJSSE 支持这两个设置,切换其他 TLS 提供者时必须保留兼容回归。

为什么 SSLParameters 设置了却没有影响 HttpClient

这里有两个容易混在一起的“成功”。调用 setNamedGroups()setSignatureSchemes() 没抛异常,只能证明 SSLParameters 接受了输入;它不等于下一次连接一定按该列表发起握手。

Oracle 的 JDK 26.0.2 修复说明把边界写得很清楚:在建立新连接时,java.net.http.HttpClient 开始使用 SSLParameters 配置的两组值,旧行为则是忽略它们。也就是说,连接池里已经建立的连接不能用来证明新参数是否被采用,回归时要创建新的 HttpClient 或确保使用新连接。

JDK 26.0.2 HttpClient、SSLParameters 与 TLS 握手之间的 named groups 和 signature schemes 关系
图1:查看 HttpClient、SSLParameters、named groups、signature schemes、SunJSSE 与 TLS 握手的边界,区分参数保存和新连接实际协商。

JDK 26.0.2 的最小配置怎么写

只需要准备一个 SSLParameters,再把它交给 HttpClient.Builder.sslParameters。数组顺序就是偏好顺序,第一项优先级最高;不要把它误写成服务端证书算法列表,也不要在这里混入 TLS 版本名。

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import javax.net.ssl.SSLParameters;

SSLParameters parameters = new SSLParameters();
parameters.setNamedGroups(new String[] {"x25519", "secp256r1"});
parameters.setSignatureSchemes(new String[] {
    "ed25519", "ecdsa_secp256r1_sha256"
});

HttpClient client = HttpClient.newBuilder()
    .sslParameters(parameters)
    .build();

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://api.example.com/health"))
    .GET()
    .build();

这段代码表达的是“客户端偏好集合”,不是强制服务端接受某一种方案。服务端没有交集、提供者不认识某个名称,或者安全策略禁止该方案时,请求仍可能在握手阶段失败。生产代码应把 JDK 版本和 TLS 提供者一起记录,不能只记录业务请求的状态码。

null、空数组和优先级数组分别代表什么

SSLParameters 对这三种状态的解释不同。最常见的误操作是为了“放开限制”传入空数组,结果反而关掉了对应的协商机制。下面把非空列表统称为优先级数组,方便和默认值、兼容回退区分。

设置状态握手语义排查重点
null使用 TLS 提供者默认值确认实际提供者与默认集合
空数组关闭对应协商机制,可能无法建立连接检查是否由配置拼接产生
非空数组按顺序覆盖提供者默认列表检查名称、顺序与服务端交集

Java SE 26 文档还提醒:提供者可以忽略不认识的名称;SunJSSE 支持 setNamedGroupssetSignatureSchemes。因此“列表里写了名称”不是验证终点,最好先用较宽的兼容集合确认链路,再逐项收窄。若改用第三方提供者,应把“是否支持这两个 API 设置”列为单独检查项。

SSLParameters 中 null、空数组和优先级数组对 SunJSSE 与 TLS 握手的静态关系
图2:查看 null、空数组、优先级数组、SunJSSE、TLS 握手和兼容回退之间的关系,判断失败来自列表过窄还是提供者能力。

升级后如何验证兼容边界

回归不要只发一次请求看 200。建议至少保留四项记录:运行时完整版本、实际 TLS 提供者、两组列表及其顺序、服务端支持范围。先不设置自定义列表确认基础链路,再只设置一组,最后同时设置两组;每次都使用新建连接,失败时保存握手异常和配置快照。

如果 JDK 26.0.2 之前的版本必须继续运行,可以把这段配置放在版本分支中,并把旧版本的“参数对象可读”与“HttpClient 握手采用”分开断言。这样升级后即便服务端策略变化,也能迅速定位是运行时版本、提供者、列表交集还是连接复用造成的差异。

常见问题

JDK 26.0.2 只修复了 HttpClient 吗?

本文讨论的变化是 HttpClient 新连接对两组 SSLParameters 的使用,不代表其他 TLS API 都发生相同语义变化。

把数组设为空是不是表示“不限制”?

不是。空数组表示关闭对应的协商机制,通常比使用提供者默认值更严格,甚至会让握手无法建立。

为什么设置了名称仍然握手失败?

优先检查提供者是否支持、名称是否有效、数组是否过窄,以及服务端是否存在共同支持项;同时确认请求确实创建了新连接。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>