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();
The error is:
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)
It was working in any previous JDK (I've tested in 7, 8, 9 and 10).
The certificate seems valid as it's recognized by browsers or most SSL test i've found in internet.
I've tried disabling host name verifying, disabling cacerts, adding the DigiCert to the cacerts file without any luck.
It seems like a bug in openJDK. Tested in build 26, 27 and 28 (release candidate).
The issue is currently resolved in JDK 12 https://bugs.openjdk.java.net/browse/JDK-8209965, and was included in ea-9.
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)
Some background to this can be found in the comments here https://github.com/openssl/openssl/pull/4463/files
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.
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.
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.
It's now solved in JDK 11.0.2, released in 16th January 2019
来源：https://stackoverflow.com/questions/52016415/jdk-11-ssl-error-on-valid-certificate-working-in-previous-versions