Ошибка 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)

Он работал в любом предыдущем JDK (я тестировал в 7, 8, 9 и 10).

Сертификат кажется действительным, поскольку он распознается браузерами или большинством тестов SSL, которые я нашел в Интернете.

Я безуспешно пытался отключить проверку имени хоста, отключить cacerts, добавить DigiCert в файл cacerts.

Похоже на ошибку в openJDK. Протестировано в сборках 26, 27 и 28 (релиз-кандидат).


person cocorossello    schedule 25.08.2018    source источник
comment
Похоже, это проблема сервера. До сих пор его принимали все клиенты, однако OpenSSL и другие стали более строгими в отношении разрешенного: mta.openssl.org/pipermail/openssl-dev/2017-October/009802.html   -  person Robert    schedule 25.08.2018
comment
Я понимаю, но флага совместимости нет (в исходниках я ничего не увидел). Таким образом, нет обходного пути, кроме как ждать, пока они исправят свой сертификат (что может занять очень много времени) или создать прокси-сервер для обхода сертификата. Это мешает нам перейти на Java 11, и это широко используемая платежная система в Испании.   -  person cocorossello    schedule 25.08.2018
comment
Это не сертификат, это сервер, отправляющий неверные данные в сообщении SERVER_HELLO.   -  person Robert    schedule 25.08.2018
comment
Извините, вы правы. Я напишу им, посмотрим, смогут ли они это исправить.   -  person cocorossello    schedule 25.08.2018
comment
bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK- 8209982   -  person cocorossello    schedule 27.08.2018
comment
Сборка JDK12-ea-9 вышла. Вы смогли проверить, исправлена ​​ли она?   -  person Naman    schedule 02.09.2018
comment
Да, я могу подтвердить, что это работает в jdk 12. Я надеюсь, что бэкпорт превратится в 11, в любом случае я нашел обходной путь, используя nginx в качестве прокси-сервера SSL, поэтому сейчас я могу использовать jdk 11.   -  person cocorossello    schedule 04.09.2018
comment
ирония здесь в том, что Tomcat — один из серверов с плохой реализацией.   -  person Eric Twilegar    schedule 17.01.2019


Ответы (2)


В настоящее время проблема решена в JDK 12 https://bugs.openjdk.java.net/browse/JDK-8209965 и был включен в ea-9.

Бэкпорт в JDK 11 также был устранен https://bugs.openjdk.java.net/browse/JDK-8210005 и включен в

  • 11.0.3 (Оракл JDK)
  • 11.0.2 (ОпенЖДК)

Некоторую информацию об этом можно найти в комментариях здесь https://github.com/openssl/openssl/pull/4463/files

TLS 1.3 добавляет схему, позволяющую серверу указывать клиенту свой список поддерживаемых групп в сообщении EncryptedExtensions, но ни одна из соответствующих спецификаций не разрешает отправку поддерживаемых_групп в сообщении ServerHello.

Тем не менее (возможно, из-за непосредственной близости к расширению «ec_point_formats», которое разрешено в ServerHello), есть несколько серверов, которые все равно отправляют это расширение в ServerHello.

Вплоть до выпуска 1.1.0 включительно мы не проверяли наличие неразрешенных расширений, поэтому, чтобы избежать регрессии, мы также должны разрешить это расширение в TLS 1.2 ServerHello.

person muttonUp    schedule 28.08.2018

Теперь эта проблема решена в JDK 11.0.2, выпущенном 16 января 2019 года.

person cocorossello    schedule 17.01.2019
comment
это действительно решено в 11.0.2? как люди сказали, что это будет решено в 11.0.3? - person nahab; 28.01.2019
comment
может другой случай - person nahab; 30.01.2019
comment
Нет, это не так. По крайней мере, не в openjdk. - person SHASHA; 18.05.2020
comment
Это решено, у вас есть контрпример? Вы пробовали образец из вопроса? почему вы говорите, что это не решено? - person cocorossello; 19.05.2020
comment
Нет, это не так. Может быть решен для вашего случая, не для всех случаев. - person SHASHA; 20.05.2020
comment
Это по поводу вопроса в топе, если у вас другой случай то уточните - person cocorossello; 20.05.2020