Java 有效证书上的JDK 11 SSL错误（在以前的版本中工作）

以下代码在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)

javax.net.ssl.SSLHandshakeException:服务器中不应显示扩展名（10）
位于java.base/sun.security.ssl.Alert.CreateSLexception（Alert.java:128）
位于java.base/sun.security.ssl.Alert.CreateSLexception（Alert.java:117）
位于java.base/sun.security.ssl.TransportContext.fatal（TransportContext.java:312）
位于java.base/sun.security.ssl.TransportContext.fatal（TransportContext.java:268）
位于java.base/sun.security.ssl.TransportContext.fatal（TransportContext.java:259）
位于java.base/sun.security.ssl.SSLExtensions（SSLExtensions.java:71）
位于java.base/sun.security.ssl.ServerHello$serverhellomemessage。（ServerHello.java:169）
位于java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.consumer（ServerHello.java:860）
位于java.base/sun.security.ssl.SSLHandshake.consume（SSLHandshake.java:390）
位于java.base/sun.security.ssl.HandshakeContext.dispatch（HandshakeContext.java:445）
位于java.base/sun.security.ssl.HandshakeContext.dispatch（HandshakeContext.java:422）
位于java.base/sun.security.ssl.TransportContext.dispatch（TransportContext.java:178）
位于java.base/sun.security.ssl.sslttransport.decode（sslttransport.java:164）
位于java.base/sun.security.ssl.SSLSocketImpl.decode（SSLSocketImpl.java:877）
位于java.base/sun.security.ssl.SSLSocketImpl.readRecord（SSLSocketImpl.java:810）
位于java.base/sun.security.ssl.SSLSocketImpl.startHandshake（SSLSocketImpl.java:383）
位于java.base/sun.net.www.protocol.https.HttpsClient.afterConnect（HttpsClient.java:567）

它在以前的任何JDK中都能工作（我在7、8、9和10中测试过）

该证书似乎有效，因为它被浏览器或我在internet上找到的大多数SSL测试所识别

我尝试过禁用主机名验证、禁用cacerts、将DigiCert添加到cacerts文件，但没有任何运气

---

这似乎是openJDK中的一个bug。在版本26、27和28（候选版本）中进行了测试。

该问题目前已在JDK 12中得到解决，并包含在ea-9中

JDK 11的后端口也已解决，并包含在

• 11.0.3（Oracle JDK）
• 11.0.2（OpenJDK）

这方面的一些背景可以在这里的评论中找到

TLS 1.3为服务器添加了一个方案，以指示 将其支持的组列表添加到客户端 EncryptedExtensions消息，但没有相关的 规范允许在服务器Hello中发送受支持的\u组

尽管如此（可能是由于靠近 “ec_point_formats”扩展名，服务器中允许使用该扩展名（Hello）， 中有多个服务器发送此扩展 你好

直到并包括1.1.0版本， 我们没有检查是否存在未经许可的扩展， 因此，为了避免回归，我们必须允许在 TLS1.2服务器你好

---

它现在在2019年1月16日发布的JDK 11.0.2中得到了解决，这似乎是服务器的问题。到目前为止，它已被所有客户机接受，但是OpenSSL和其他已开始对允许的内容更加严格：我理解，但没有兼容标志（我在源代码中看不到任何内容）。因此，除了等待他们修复证书（可能需要很长时间）或创建“代理”服务器以绕过证书之外，没有其他解决方法。这阻止了我们升级到java 11，它是spainIt中广泛使用的支付系统。不是证书，而是服务器在服务器\u HELLO消息中发送错误数据。对不起，你是对的。我会写下来，让我们看看他们是否能解决它。它真的在11.0.2中解决了吗？正如人们所说，它将在11.0.3解决？可能是另一种情况不，它不是。至少在openjdk中没有。问题已经解决了，你有反例吗？你试过问题中的样本了吗？你为什么说问题没有解决？不，没有。可能会为您的案件解决，而不是所有案件。