有效证书上的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 并将包含在11.0.3（eta Q2 + 2019）中
The backport to JDK 11 has also been resolved https://bugs.openjdk.java.net/browse/JDK-8210005 and will be included in 11.0.3 (eta Q2+ 2019)
此处的评论可以在中找到。 https://github.com/openssl/openssl/pull/4463/files
TLS 1.3增加了一个方案服务器在
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屋！
