it-swarm.com.de

JDK 11 SSL-Fehler bei gültigem Zertifikat (funktioniert in früheren Versionen)

Der folgende Code löst einen Fehler in JDK 11 aus:

    HttpURLConnection con = (HttpURLConnection) new URL("https://sis.redsys.es/sis/realizarPago").openConnection();
    con.setRequestMethod("GET");
    con.getResponseCode();

Der Fehler ist:

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)

Es hat in jedem vorherigen JDK funktioniert (ich habe es in 7, 8, 9 und 10 getestet). 

Das Zertifikat scheint gültig zu sein, da es von Browsern oder den meisten SSL-Tests erkannt wird, die ich im Internet gefunden habe.

Ich habe versucht, die Überprüfung des Hostnamens zu deaktivieren, Cacerts zu deaktivieren und DigiCert ohne Erfolg der Cacerts-Datei hinzuzufügen.

Es scheint ein Fehler in openJDK zu sein. Getestet in Build 26, 27 und 28 (Veröffentlichungskandidat).

8
cocorossello

Das Problem ist derzeit in JDK 12 https://bugs.openjdk.Java.net/browse/JDK-8209965 behoben und in ea-9 enthalten.

Der Backport zu JDK 11 wurde ebenfalls behoben https://bugs.openjdk.Java.net/browse/JDK-8210005 und wird in 11.0.3 enthalten (eta Q2 + 2019)

Hintergrundinformationen dazu finden Sie in den Kommentaren hier https://github.com/openssl/openssl/pull/4463/files

TLS 1.3 fügt ein Schema für den Server hinzu, um anzugeben dem Client die Liste der unterstützten Gruppen in der EncryptedExtensions-Nachricht, jedoch keine der relevanten Spezifikationen erlauben das Versenden von Supports_groups im ServerHello.

Nichtsdestotrotz (möglicherweise aufgrund der Nähe zu der Erweiterung "Ec_point_formats", die im ServerHello zulässig ist), Es gibt mehrere Server, die diese Erweiterung in der .__ senden. ServerHello trotzdem. 

Bis einschließlich 1.1.0, Wir haben nicht auf das Vorhandensein nicht zulässiger Erweiterungen geprüft. Um eine Regression zu vermeiden, müssen wir diese Erweiterung in der .__ zulassen. TLS 1.2 ServerHello auch.

9
muttonUp

Es wurde jetzt in JDK 11.0.2 gelöst, das am 16. Januar 2019 veröffentlicht wurde

0
cocorossello