Отримано фатальне сповіщення: рукостискання_помилка через SSLHandshakeException


134

У мене проблема з авторизованим підключенням SSL. Я створив Struts Action, який підключається до зовнішнього сервера за допомогою сертифікованого клієнта SSL-сертифіката. У своїй дії я намагаюся надіслати деякі дані на банківський сервер, але без жодної удачі, тому що у мене з'явилася така помилка:

error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Мій метод з класу Дія, який надсилає дані на сервер

//Getting external IP from host
    URL whatismyip = new URL("http://automation.whatismyip.com/n09230945.asp");
    BufferedReader inIP = new BufferedReader(new InputStreamReader(whatismyip.openStream()));

    String IPStr = inIP.readLine(); //IP as a String

    Merchant merchant;

    System.out.println("amount: " + amount + ", currency: " + currency + ", clientIp: " + IPStr + ", description: " + description);

    try {

        merchant = new Merchant(context.getRealPath("/") + "merchant.properties");

    } catch (ConfigurationException e) {

        Logger.getLogger(HomeAction.class.getName()).log(Level.INFO, "message", e);
        System.err.println("error: " + e.getMessage());
        return ERROR;
    }

    String result = merchant.sendTransData(amount, currency, IPStr, description);

    System.out.println("result: " + result);

    return SUCCESS;

Мій файл merchant.properties:

bank.server.url=https://-servernameandport-/
https.cipher=-cipher-

keystore.file=-key-.jks
keystore.type=JKS
keystore.password=-password-
ecomm.server.version=2.0

encoding.source=UTF-8
encoding.native=UTF-8

Вперше я подумав, що це проблема сертифікатів, я перетворив її з .pfx в .jks, але у мене така ж помилка, без змін.


Ви додали ssl cert сервера до свого довіреного магазину?
happymeal

Вибачте, я не розумію, що це означає, я новачок у SSL
Denees

я припускаю, що ваш додаток використовує довірену сховище Java за замовчуванням. За замовчуванням довірений магазин <java-home> / lib / security / cacerts. відкрийте URL-адресу сервера у своєму браузері та завантажте всі ssl-серти; включаючи будь-які цементні / проміжні серти. потім додайте всі ці серти до довіреного магазину.
happymeal

Я не можу відкрити URL-адресу в браузері, оскільки сертифікат автентифікації клієнта я можу надсилати на це посилання лише певні параметри, які я отримую від клієнтів.
Denees

просто відкрийте URL-адресу. ігноруйте всі помилки, які ви бачите у своєму браузері. коли ви отримуєте доступ до URL-адреси, ви побачите значок замка на адресному рядку веб-переглядача. натисніть на це і завантажте ssl cert сервера.
happymeal

Відповіді:


251

Поломка рукостискання могла статися через різні причини:

  • Несумісні шифрові пакети, якими користуються клієнт і сервер. Це вимагає від клієнта використання (або включення) набору шифрів, який підтримується сервером.
  • Несумісні версії SSL у використанні (сервер може приймати тільки TLS v1, тоді як клієнт може використовувати тільки SSL v3). Знову ж, клієнту, можливо, доведеться використовувати сумісну версію протоколу SSL / TLS.
  • Неповний шлях довіри для сертифіката сервера; сертифікату сервера, ймовірно, клієнт не довіряє. Зазвичай це призведе до більш детальної помилки, але це цілком можливо. Зазвичай виправлення полягає в імпорті сертифікату CA сервера в сховище клієнта.
  • Сертифікат видається для іншого домену. Знову ж таки, це призвело б до більш детального повідомлення, але я викладу тут виправлення у випадку, якщо це причина. У цьому випадку рішення дозволить серверу (він, здається, не є вашим), використовувати правильний сертифікат.

Оскільки базовий збій неможливо визначити, краще включити -Djavax.net.debug=allпрапор, щоб увімкнути налагодження встановленого SSL-з'єднання. Увімкнувши налагодження, ви можете точно визначити, яка діяльність в рукостисканні не вдалася.

Оновлення

Виходячи з наявних зараз деталей, виявляється, що проблема пов’язана з неповним довірчим шляхом довіри між сертифікатом, виданим сервером, і кореневим CA. У більшості випадків це відбувається через те, що кореневий сертифікат CA відсутній у сховищі довіри, що призводить до ситуації, коли шлях довіри сертифіката не може існувати; сертифікат по суті не є довіреним клієнтом. Браузери можуть подавати попередження, щоб користувачі могли проігнорувати це, але те ж саме не стосується клієнтів SSL (наприклад, клас HttpsURLConnection або будь-яка бібліотека клієнтів HTTP, наприклад Apache HttpComponents Client ).

Більшість цих класів / бібліотек клієнтів покладаються на сховище довіри, яке використовує JVM для перевірки сертифікатів. У більшості випадків це cacertsфайл у каталозі JRE_HOME / lib / security. Якщо розташування довіреного магазину було вказано за допомогою властивості системи JVM javax.net.ssl.trustStore, то зберігання на цьому шляху зазвичай є тим, що використовується клієнтською бібліотекою. Якщо ви сумніваєтесь, погляньте на свій Merchantклас та з’ясуйте клас / бібліотеку, яку він використовує для встановлення з'єднання.

Додавання сервера, що видає сертифікат сервера, до цього довіреного магазину, має вирішити проблему. Ви можете звернутися до моєї відповіді на пов'язане питання щодо отримання інструментів для цієї мети, але для цієї мети достатньо утиліти Java keytool .

Попередження : Магазин довіри - це, по суті, перелік усіх ЦП, яким Ви довіряєте. Якщо ви помістите сертифікат, який не належить до ЦС, якому ви не довіряєте, то з'єднання SSL / TLS до сайтів, що мають сертифікати, видані цією особою, можуть бути розшифровані, якщо приватний ключ доступний.

Оновлення №2: Розуміння результату трасування JSSE

Магазин брелоків і довірені магазини, якими користується JVM, зазвичай перераховані на самому початку, дещо як наступне:

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 

Якщо використовується неправильна сховище довіри, вам потрібно буде повторно імпортувати сертифікат сервера на потрібний або перенастроїти сервер, щоб використовувати вказаний (не рекомендується, якщо у вас кілька JVM, і всі вони використовуються для різних потреби).

Якщо ви хочете перевірити, чи містить список довірених сертифікатів потрібні серти, то для них є розділ, який починається з:

adding as trusted cert:
  Subject: CN=blah, O=blah, C=blah
  Issuer:  CN=biggerblah, O=biggerblah, C=biggerblah
  Algorithm: RSA; Serial number: yadda
  Valid from SomeDate until SomeDate

Вам потрібно буде шукати, чи є ЦС сервера предметом.

Процес рукостискання матиме кілька чітких записів (вам потрібно знати SSL, щоб їх детально зрозуміти, але для налагодження поточної проблеми достатньо знати, що рукостискання_файлу зазвичай повідомляється в ServerHello.

1. КлієнтЗдрастуйте

Під час ініціалізації з'єднання буде повідомлено про ряд записів. Перше повідомлення, надіслане клієнтом у налаштуваннях з'єднання SSL / TLS, - це повідомлення ClientHello, яке зазвичай повідомляється в журналах як:

*** ClientHello, TLSv1
RandomCookie:  GMT: 1291302508 bytes = { some byte array }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***

Зверніть увагу на використовувані набір шифрів. Це, можливо, доведеться погодитись із записом у вашому файлі merchant.properties, оскільки ця ж конвенція може бути використана бібліотекою банку. Якщо застосовувана конвенція відрізняється, немає ніяких причин для занепокоєння, оскільки ServerHello зазначатиме так, якщо пакет шифрів несумісний.

2. СерверHello

Сервер відповідає за допомогою ServerHello, який вказуватиме, чи може продовжуватися налаштування з'єднання. Записи в журналах зазвичай бувають такого типу:

*** ServerHello, TLSv1
RandomCookie:  GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***

Зверніть увагу на шифр, який він вибрав; найкраще це доступний як для сервера, так і для клієнта. Зазвичай шифр не задається, якщо є помилка. Сертифікат сервера (і, можливо, всієї ланцюга) надсилається сервером, і він буде знайдений у записах як:

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
  Signature Algorithm: SHA1withRSA, OID = some identifer

.... the rest of the certificate
***

Якщо перевірка сертифіката вдалася, ви знайдете запис, подібний до:

Found trusted certificate:
[
[
  Version: V1
  Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
  Signature Algorithm: SHA1withRSA, OID = some identifier

Один з перерахованих вище кроків не вдався б, внаслідок чого рукостискання_файл, оскільки рукостискання на цій стадії зазвичай завершено (не дуже, але наступні етапи рукостискання зазвичай не викликають зриву рукостискання). Вам потрібно буде з'ясувати, який крок не вдався, і опублікувати відповідне повідомлення як оновлення питання (якщо ви вже не зрозуміли повідомлення, і не знаєте, що робити для його вирішення).


Будь ласка, опублікуйте все, що у вас є, якщо зможете, щоб я міг оновити відповідь більш конкретною.
Vineet Reynolds

1
Ok Vineet, я не можу зрозуміти, як з цим боротися, я вже виснажений. Я знайшов спосіб перевірити URL-адресу сервера openssl "openssl s_client -connect ім'я сервера: 4402" і подивитися, що я отримав: img225.imageshack.us/img225/8999/screenshoturr.png
Denees

@hoss, схоже, сертифікат сервера був виданий суб'єктом господарювання, який не присутній у магазині довіри, який використовується OpenSSL, а також, можливо, не присутній у сховищі довіри, використовуваному вашим сервером (клієнтом), коли він підключається до сервер. У такому випадку вам потрібно буде імпортувати сертифікат ЦС, який видав сертифікат ( а не сервер ), у довірений магазин вашого клієнта (OpenSSL / ваш сервер).
Vineet Reynolds

1
Ну, може, це покладається на кацетери. Але це можна визначити, лише якщо ви розумієте вихід налагодження в мережі. Якщо ви хочете перевірити це, вам потрібно буде скористатися keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacertsкомандою для друку вмісту. Потім перевірте, чи відповідають сертифікати в касертах сертифікату банку.
Vineet Reynolds

5
За замовчуванням зазвичай changeit. Якщо тільки не було змінено.
Vineet Reynolds

20

Установка Java Cryptography Extension (JCE) Необмежена сила ( для JDK7 | для JDK8 ) може виправити цю помилку. Розпакуйте файл і дотримуйтесь readme, щоб встановити його.


16

Невдача рукостискання може бути помилковою реалізацією протоколу TLSv1.

У нашому випадку це допомогло з java 7:

java -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1 

Jvm веде переговори в цьому порядку. Сервери з останнім оновленням виконають 1,2, баггі знизяться до v1, і це працює з аналогічним v1 в java 7.


1
Це мені допомогло. Був мій ClientHello, але сервера немає, кінець був досить крутим. Це зафіксувало мене на Java 7. Дякую.
virgo47

15

Це також може статися, коли клієнту необхідно пред'явити сертифікат. Після того, як сервер перелічить ланцюжок сертифікатів, може статися таке:

3. Запит на сертифікат Сервер видає клієнту запит на сертифікат. У запиті будуть перелічені всі сертифікати, які приймає сервер.

*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<CN=blah, OU=blah, O=blah, L=blah, ST=blah, C=blah>
<CN=yadda, DC=yadda, DC=yadda>
<CN=moreblah, OU=moreblah, O=moreblah, C=moreblah>
<CN=moreyada, OU=moreyada, O=moreyada, C=moreyada>
... the rest of the request
*** ServerHelloDone

4. Ланцюг сертифікатів клієнта Це сертифікат, який клієнт надсилає серверу.

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: EMAILADDRESS=client's email, CN=client, OU=client's ou, O=client's Org, L=client's location, ST=client's state, C=client's Country
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  ... the rest of the certificate
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1    
... key exchange info 

Якщо у ланцюзі немає сертифіката, а сервер вимагає такого, тут ви отримаєте помилку рукостискання. Ймовірна причина - шлях до вашого сертифіката не знайдено.

5. Підтвердження сертифікату Клієнт просить сервер перевірити сертифікат

*** CertificateVerify
... payload of verify check

Цей крок відбудеться лише в тому випадку, якщо ви надсилаєте сертифікат.

6. Готово Сервер відповість підтвердженням відповіді

*** Finished
verify_data:  { 345, ... }

у моєму випадку здається, що всі кроки є нормальними, але все-таки отримують помилку рукостискання.
тибі

дуже приємна відповідь ... але все це нормально в моєму відмові від рукостискання, але все-таки у мене відмова. ви могли поглянути на моє подібне запитання?
тибі

Якщо не представити клієнтський сертифікат, це не будь-яка помилка в TLS. Якщо для сервера потрібен сертифікат клієнта, а його немає, він закриє з'єднання.
Маркіз Лорн

@EJP правда, це не помилка в TLS, однак невдале з'єднання виявляється помилкою в коді Java.
Бріг

1
@Brig Але не як попередження, про що йдеться у цій відповіді, і в чому питання.
Маркіз Лорн

15

Я не думаю, що це вирішує проблему для першого запитувача, але для Google, які приходять сюди за відповідями:


Оновлення 51, java 1.8 заборонено [1] шифри RC4 за замовчуванням, як ми бачимо на сторінці Примітки до випуску:

Виправлення помилок: заборонити набір шифрів RC4

RC4 зараз розглядається як компрометований шифр.

Набір шифрів RC4 було видалено зі списку шифрів, включених як клієнт, так і сервер за замовчуванням у реалізації Oracle JSSE. Ці набір шифрів все ще можна вмикати за допомогою SSLEngine.setEnabledCipherSuites()та SSLSocket.setEnabledCipherSuites()методами. Див. JDK-8077109 (не загальнодоступний).

Якщо ваш сервер має перевагу перед цим шифром (або використовувати лише цей шифр), це може спричинити handshake_failureпояву Java.

Ви можете перевірити підключення до сервера, що дозволяє шифрувати RC4 (спочатку спробуйте без enabledаргументів, щоб переконатися, що тригери a handshake_failure, а потім встановити enabled:

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;

import java.util.Arrays;

/** Establish a SSL connection to a host and port, writes a byte and
 * prints the response. See
 * http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services
 */
public class SSLRC4Poke {
    public static void main(String[] args) {
        String[] cyphers;
        if (args.length < 2) {
            System.out.println("Usage: "+SSLRC4Poke.class.getName()+" <host> <port> enable");
            System.exit(1);
        }
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(args[0], Integer.parseInt(args[1]));
        
            cyphers = sslsocketfactory.getSupportedCipherSuites();
            if (args.length ==3){
                sslsocket.setEnabledCipherSuites(new String[]{
                    "SSL_DH_anon_EXPORT_WITH_RC4_40_MD5",
                    "SSL_DH_anon_WITH_RC4_128_MD5",
                    "SSL_RSA_EXPORT_WITH_RC4_40_MD5",
                    "SSL_RSA_WITH_RC4_128_MD5",
                    "SSL_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_anon_WITH_RC4_128_SHA",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_MD5",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_SHA",
                    "TLS_KRB5_WITH_RC4_128_MD5",
                    "TLS_KRB5_WITH_RC4_128_SHA"
                });     
            }

            InputStream in = sslsocket.getInputStream();
            OutputStream out = sslsocket.getOutputStream();

            // Write a test byte to get a reaction :)
            out.write(1);

            while (in.available() > 0) {
                System.out.print(in.read());
            }
            System.out.println("Successfully connected");

        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}

1 - https://www.java.com/en/download/faq/release_changes.xml


10

У мене є ця помилка, коли я намагався використовувати JDK 1.7. Коли я модернізував JDK до jdk1.8.0_66, все почало працювати нормально.

Тож найпростішим рішенням цієї проблеми могло бути - оновити JDK, і воно може почати працювати добре.


4
Приємно. Найпростіше рішення - оновити JDK? : D Чи знаєте ви, наскільки складно це може бути залежно від середовища, де це робиться? Припустимо, Amazon запустив JDK 7 і тепер йому потрібно буде раптово оновити JDK 8 ... Приємно!
Артурас М

1
Просте оновлення незначної версії вирішило цю проблему для мене .. від JDK 11.0.1 до 11.0.6
Клінт

4

У моєму випадку cert імпортується, залишається помилка, вирішується це шляхом додавання System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3");перед підключенням


Працював для мене в java 1.8. Дякую :)
Supun Amarasinghe

3

Припустимо, що ви використовуєте належні протоколи SSL / TLS, правильно налаштували свої keyStoreта trustStoreта підтвердили, що проблем із самими сертифікатами не існує, можливо, вам знадобиться посилити алгоритми захисту .

Як згадується у відповіді Vineet , одна з можливих причин, коли ви отримуєте цю помилку, пов’язана з використанням несумісних шифрових пакетів. Оновивши мій local_policyта US_export_policyбанки в securityпапці мого JDK з тими, які надані в розширенні криптографії Java (JCE) , я зміг успішно завершити рукостискання.


2

Я зустрічаюсь з тією ж проблемою сьогодні з клієнтом OkHttp, щоб отримати URL на основі https. Це було викликано версією протоколу Https та невідповідністю методу Cipher між стороною сервера та клієнтом .

1) перевірте версію протоколу https свого веб-сайту та метод Cipher.

openssl>s_client -connect your_website.com:443 -showcerts

Ви отримаєте багато детальної інформації, ключова інформація вказана наступним чином:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
2) конфігуруйте свій http-клієнт, наприклад, у випадку клієнта OkHttp :
@Test()
public void testHttpsByOkHttp() {
    ConnectionSpec spec = new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
            .tlsVersions(TlsVersion.TLS_1_0) //protocol version
            .cipherSuites(
                    CipherSuite.TLS_RSA_WITH_RC4_128_SHA, //cipher method
                    CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256)
            .build();

    OkHttpClient client = new OkHttpClient();
    client.setConnectionSpecs(Collections.singletonList(spec));
    Request request = new Request.Builder().url("https://your_website.com/").build();
    try {
        Response response = client.newCall(request).execute();
        if(response.isSuccessful()){
            logger.debug("result= {}", response.body().string());
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Це отримає те, що ми хочемо.


2

Я знайшов сервер HTTPS, який не вдався таким чином, якщо мій клієнтський процес Java був налаштований

-Djsse.enableSNIExtension=false

З'єднання не вдалося завершити handshake_failureпісля ServerHelloуспішного завершення, але до початку потоку даних.

Не було чіткого повідомлення про помилку, яке визначило б проблему, помилка просто виглядала

main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
%% Invalidated:  [Session-3, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Я виокремив проблему, намагаючись із " -Djsse.enableSNIExtension=false" опцією та без неї


Я отримую таку ж помилку під час підключення до пісочниці GDAX, якісь рішення для цього?
Нітін Вавдія

1

Моя TLSпомилка була несумісною з версією.

Раніше це TLSv1я змінив, це TLSV1.2вирішило мою проблему.


1

Я використовую http-клієнт com.google.api. Під час спілкування з внутрішнім сайтом компанії, у мене виникла ця проблема, коли я помилково використовував https, а не http.

main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, IOException in getSession():  javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
262 [main] DEBUG org.apache.http.impl.conn.DefaultClientConnection  - Connection shut down
main, called close()
main, called closeInternal(true)
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager  - Released connection is not reusable.
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Releasing connection [HttpRoute[{s}->https://<I-replaced>]][null]
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Notifying no-one, there are no waiting threads
Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
    at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
    at com.google.api.client.http.apache.ApacheHttpRequest.execute(ApacheHttpRequest.java:67)
    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:960)

Ні, ти не можеш. Сервер не може надсилати попередження TLS, якщо він не говорить TLS.
Маркіз Лорн

Я оновив свій коментар, щоб показати результати своєї програми. Це реально. Будемо вдячні, якщо ви видалите голосування.
thebiggestlebowski

Це реально, але це не викликано розмовою TLS з сервером простого тексту. Сервер простого тексту не розмовляє з TLS за визначенням, і, отже, ви не зможете отримувати повідомлення про TLS від нього за визначенням. Ви не маєте жодної інформації про те, хто спростував вашу відповідь.
Маркіз Лорн

Я припускав, що ти проголосував - мої вибачення, якщо це не так. Моє повідомлення про помилку точно відповідає заголовку цього питання. Це дійсний шлях / тест, щоб отримати це повідомлення про помилку, і у мене є рішення, яке може допомогти іншим. З повагою, я не думаю, що це має значення, чи це викликано реакцією на помилку сервера TLS чи ні. Хтось приземлиться сюди з google, і моя відповідь може допомогти, якщо вони зробили таку ж помилку.
thebiggestlebowski

Я нічого не сказав про ваше повідомлення про помилку. Я коментую вашу неправильну заяву, що вона пов’язана з "помилковим використанням HTTPS замість HTTP". З причин, про які я заявив і з яких ви жодним чином не зверталися, це не так, і не може бути. Використання HTTP, безумовно, змусить його піти, очевидно, оскільки немає TLS-сповіщень у простому тексті, але не вирішує основної проблеми.
Маркіз Лорн

1

У мене було подібне питання; оновлення до Apache HTTPClient 4.5.3 виправлено.


1

Угг! Це виявилося для мене просто проблемою версії Java. Я отримав помилку рукостискання за допомогою JRE 1.6, і все працювало чудово за допомогою JRE 1.8.0_144.


0

Відмова: Я не знаю, чи відповідь буде корисною для багатьох людей, просто поділитися, бо це може.

Я отримував цю помилку під час використання Parasoft SOATest для надсилання запиту XML (SOAP).

Проблема полягала в тому, що я вибрав неправильний псевдонім зі спадного меню після додавання сертифіката та автентифікації.


0

У моєму випадку веб-сайт просто може використовувати TLSv1.2. і я використовую apache httpclient 4.5.6, я використовую цей код і встановлюю jce, щоб вирішити це (JDK1.7):

jce

jdk7 http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

jdk 8 http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

код:

SSLContext sslContext = SSLContext.getDefault();

  SSLConnectionSocketFactory sslConnectionFactory = new SSLConnectionSocketFactory(
      sslContext,
      new String[]{"TLSv1.2"}, // important
      null,
      NoopHostnameVerifier.INSTANCE);

  Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
      .register("https", sslConnectionFactory)
      .register("http", PlainConnectionSocketFactory.INSTANCE)
      .build();

  HttpClientConnectionManager ccm = new BasicHttpClientConnectionManager(registry);
  httpclient = HttpClientBuilder.create().
      .setSSLSocketFactory(sslConnectionFactory)
      .setConnectionManager(ccm)
      .build();

0

Щоб вирішити проблеми з точки зору розробника (пункт 1) та системного адміністратора (пункти 2 і 3):

  1. Увімкніть налагодження SSL рукостискання на Java через -Djavax.net.debug=ssl:handshake:verbose.
  2. Встановіть ssldump на сервер через sudo apt install ssldumpабо компілюйте з джерела, перейшовши за цим посиланням, якщо ви спостерігаєте Unknown valueза шифром, коли ви виконуєте нижче кроку.
  3. На сервері, sudo ssldump -k <your-private-key> -i <your-network-interface>
  4. Перевірте журнал про реальну причину відмови.

Приклад непрацюючого рукостискання журналу ssldump:

New TCP connection #1: 10.1.68.86(45308) <-> 10.1.68.83(5671)
1 1  0.0111 (0.0111)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  0.0122 (0.0011)  S>C  Alert
    level           fatal
    value           insufficient_security
1    0.0126 (0.0004)  S>C  TCP RST

Приклад успішного рукостискання журналу ssldump

New TCP connection #1: 10.1.68.86(56558) <-> 10.1.68.83(8443)
1 1  0.0009 (0.0009)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        Unknown value 0xcca9
        Unknown value 0xcca8
        Unknown value 0xccaa
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  0.0115 (0.0106)  S>C  Handshake
      ServerHello
        Version 3.3
        session_id[0]=

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
1 3  0.0115 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0115 (0.0000)  S>C  Handshake
      ServerKeyExchange
Not enough data. Found 294 bytes (expecting 32767)
1 5    0.0115   (0.0000)    S>C    Handshake
        ServerHelloDone
1 6    0.0141   (0.0025)    C>S    Handshake
        ClientKeyExchange
Not enough data. Found 31 bytes (expecting 16384)
1 7    0.0141   (0.0000)    C>S    ChangeCipherSpec
1 8    0.0141   (0.0000)    C>S      Handshake
1 9    0.0149   (0.0008)    S>C    Handshake
1 10   0.0149   (0.0000)    S>C    ChangeCipherSpec
1 11   0.0149   (0.0000)    S>C      Handshake

Приклад непрацюючого журналу Java

javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.778 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.779 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.779 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: T LS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.787 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|WARNING|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.818 MYT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers
javax.net.ssl|WARNING|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.818 MYT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers
javax.net.ssl|ALL|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.822 MYT|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5
javax.net.ssl|INFO|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.822 MYT|AlpnExtension.java:161|No available application protocols
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.823 MYT|SSLExtensions.java:256|Ignore, context unavailable extension: application_layer_protocol_negotiation
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.823 MYT|SSLExtensions.java:256|Ignore, context unavailable extension: renegotiation_info
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.825 MYT|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "FB BC CD 7C 17 65 86 49 3E 1C 15 37 24 94 7D E7 60 44 1B B8 F4 18 21 D0 E1 B1 31 0D E1 80 D6 A7",
  "session id"          : "",
  "cipher suites"       : "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=mq.tpc-ohcis.moh.gov.my
    },
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },
    "supported_groups (10)": {
      "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }      }
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "supported_versions (43)": {
      "versions": [TLSv1.2, TLSv1.1, TLSv1]
    }
  ]
}
)
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.829 MYT|Alert.java:238|Received alert message (
"Alert": {
  "level"      : "fatal",
  "description": "insufficient_security"
}
)

0

У моєму випадку у мене був один випуск із версією 1.1. Я легко відтворював проблему завитком. Сервер не підтримував нижчі версії, ніж TLS1.2.

Це отримало проблему рукостискання:

curl --insecure --tlsv1.1 -i https://youhost --noproxy "*"

З версією 1.2 він працював чудово:

curl --insecure --tlsv1.2 -i https://youhost --noproxy "*"

Сервер запускав Weblogic, і додавши цей аргумент у setEnvDomain.sh, він змусив його працювати з TLSv1.1:

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1

0

Ця проблема виникає через версію java. Я використовував 1.8.0.231 JDK і отримував цю помилку. Я деградував свою версію Java з 1.8.0.231 до 1.8.0.171, зараз вона працює чудово.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.