有效证书上的 JDK 11 SSL 错误(在以前的版本中工作) [英] JDK 11 SSL Error on valid certificate (working in previous versions)
问题描述
以下代码在 JDK 11 中引发错误:
The following code throws an error in JDK 11:
HttpURLConnection con = (HttpURLConnection) new URL("https://sis.redsys.es/sis/realizarPago").openConnection();
con.setRequestMethod("GET");
con.getResponseCode();
错误是:
javax.net.ssl.SSLHandshakeException: extension (10) should not be presented in server_hello
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.SSLExtensions.<init>(SSLExtensions.java:71)
at java.base/sun.security.ssl.ServerHello$ServerHelloMessage.<init>(ServerHello.java:169)
at java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.consume(ServerHello.java:860)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:390)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:445)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
它可以在任何以前的 JDK 中工作(我已经在 7、8、9 和 10 中进行了测试).
It was working in any previous JDK (I've tested in 7, 8, 9 and 10).
该证书似乎有效，因为它被浏览器或我在互联网上找到的大多数 SSL 测试所识别.
The certificate seems valid as it's recognized by browsers or most SSL test i've found in internet.
我试过禁用主机名验证、禁用 cacerts、将 DigiCert 添加到 cacerts 文件中，但没有任何运气.
I've tried disabling host name verifying, disabling cacerts, adding the DigiCert to the cacerts file without any luck.
这似乎是 openJDK 中的一个错误.在构建 26、27 和 28(候选发布版)中进行了测试.
It seems like a bug in openJDK. Tested in build 26, 27 and 28 (release candidate).
推荐答案
该问题目前已在 JDK 12 中解决 https://bugs.openjdk.java.net/browse/JDK-8209965，已包含在 ea-9 中.
The issue is currently resolved in JDK 12 https://bugs.openjdk.java.net/browse/JDK-8209965, and was included in ea-9.
向后移植到 JDK 11 的问题也已解决 https://bugs.openjdk.java.net/browse/JDK-8210005 并包含在
The backport to JDK 11 has also been resolved https://bugs.openjdk.java.net/browse/JDK-8210005 and is included in
- 11.0.3 (Oracle JDK)
- 11.0.2 (OpenJDK)
可以在此处的评论中找到有关此的一些背景https://github.com/openssl/openssl/pull/4463/files
Some background to this can be found in the comments here https://github.com/openssl/openssl/pull/4463/files
TLS 1.3 为服务器增加了一个scheme来表明向客户端发送其支持的组列表EncryptedExtensions 消息，但没有相关的规范允许在 ServerHello 中发送 supported_groups.
TLS 1.3 adds a scheme for the server to indicate to the client its list of supported groups in the EncryptedExtensions message, but none of the relevant specifications permit sending supported_groups in the ServerHello.
尽管如此(可能是因为靠近ec_point_formats"扩展名，在ServerHello中是允许的)，有几台服务器在无论如何，ServerHello.
Nonetheless (possibly due to the close proximity to the "ec_point_formats" extension, which is allowed in the ServerHello), there are several servers that send this extension in the ServerHello anyway.
直到并包括 1.1.0 版本，我们没有检查是否存在不允许的扩展，所以为了避免回归，我们必须在TLS 1.2 ServerHello 也是如此.
Up to and including the 1.1.0 release, we did not check for the presence of nonpermitted extensions, so to avoid a regression, we must permit this extension in the TLS 1.2 ServerHello as well.
这篇关于有效证书上的 JDK 11 SSL 错误(在以前的版本中工作)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
