Otrzymano alert krytyczny: handshake_failure przez SSLHandshakeException

137

Mam problem z autoryzowanym połączeniem SSL. Stworzyłem Struts Action, który łączy się z zewnętrznym serwerem z certyfikatem SSL Client Authorized. W mojej Akcji próbuję przesłać dane na serwer banku, ale bez powodzenia, ponieważ w wyniku działania serwera mam następujący błąd:

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

Moja metoda z mojej klasy Action, która wysyła dane do serwera

//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;

Mój plik 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

Po raz pierwszy pomyślałem, że to problem z certyfikatem, przekonwertowałem go z .pfx na .jks, ale mam ten sam błąd, bez zmian.

java ssl ssl-certificate sslhandshakeexception Denees
źródło
czy dodałeś certyfikat ssl serwera do swojego magazynu zaufanych certyfikatów?
happymeal
przepraszam, nie rozumiem, co to znaczy, jestem nowy w SSL
Denees
Zakładam, że Twoja aplikacja korzysta z domyślnego magazynu zaufanych certyfikatów Java. Domyślny magazyn zaufanych certyfikatów to <java-home> / lib / security / cacerts. otwórz adres URL serwera w przeglądarce i pobierz wszystkie certyfikaty ssl; w tym wszelkie certyfikaty łańcuchowe / pośrednie. następnie dodaj wszystkie te certyfikaty do magazynu zaufanych certyfikatów.
happymeal
Nie mogę otworzyć adresu URL w przeglądarce, ze względu na certyfikat uwierzytelniający klienta mogę przesłać na ten link tylko określone parametry, które otrzymuję od klientów.
Denees
po prostu otwórz adres URL. zignoruj ​​wszystkie błędy, które widzisz w swojej przeglądarce. kiedy uzyskujesz dostęp do adresu URL, na pasku adresu przeglądarki powinna pojawić się ikona kłódki. kliknij na to i pobierz certyfikat ssl serwera.
happymeal

Odpowiedzi:

258

Błąd uzgadniania mógł wystąpić z różnych powodów:

  • Niezgodne zestawy szyfrów używane przez klienta i serwer. Wymagałoby to od klienta użycia (lub włączenia) zestawu szyfrów obsługiwanego przez serwer.
  • Używane niezgodne wersje SSL (serwer może akceptować tylko TLS v1, podczas gdy klient może używać tylko SSL v3). Ponownie, klient może być zmuszony do upewnienia się, że używa kompatybilnej wersji protokołu SSL / TLS.
  • Niekompletna ścieżka zaufania dla certyfikatu serwera; certyfikat serwera prawdopodobnie nie jest zaufany przez klienta. Zwykle powodowałoby to bardziej szczegółowy błąd, ale jest całkiem możliwe. Zwykle rozwiązaniem jest zaimportowanie certyfikatu CA serwera do magazynu zaufanych certyfikatów klienta.
  • Certyfikat wydawany jest dla innej domeny. Ponownie spowodowałoby to bardziej szczegółowy komunikat, ale podam tutaj poprawkę na wypadek, gdyby to była przyczyna. Rozwiązanie w tym przypadku byłoby takie, aby serwer (nie wygląda na Twój) używał prawidłowego certyfikatu.

Ponieważ nie można wskazać podstawowej awarii, lepiej jest włączyć -Djavax.net.debug=allflagę, aby umożliwić debugowanie nawiązanego połączenia SSL. Przy włączonym debugowaniu można określić, jakie działanie podczas uzgadniania nie powiodło się.

Aktualizacja

Na podstawie obecnie dostępnych szczegółów wydaje się, że problem jest spowodowany niepełną ścieżką zaufania certyfikatu między certyfikatem wydanym na serwerze a głównym urzędem certyfikacji. W większości przypadków jest to spowodowane brakiem certyfikatu głównego urzędu certyfikacji w magazynie zaufanych certyfikatów, co prowadzi do sytuacji, w której ścieżka zaufania certyfikatu nie może istnieć; certyfikat jest zasadniczo niezaufany przez klienta. Przeglądarki mogą wyświetlać ostrzeżenie, aby użytkownicy mogli to zignorować, ale to samo nie dotyczy klientów SSL (takich jak klasa HttpsURLConnection lub dowolna biblioteka klienta HTTP, taka jak klient Apache HttpComponents ).

Większość tych klas / bibliotek klienta polegałaby na magazynie zaufanych certyfikatów używanym przez maszynę JVM do sprawdzania poprawności certyfikatu. W większości przypadków będzie to cacertsplik w katalogu JRE_HOME / lib / security. Jeśli lokalizacja zaufanego magazynu została określona przy użyciu właściwości systemowej maszyny JVM javax.net.ssl.trustStore, wówczas magazyn w tej ścieżce jest zwykle tym, który jest używany przez bibliotekę klienta. Jeśli masz wątpliwości, spójrz na swoją Merchantklasę i dowiedz się, której klasy / biblioteki używa do nawiązania połączenia.

Dodanie urzędu certyfikacji wystawiającego certyfikat serwera do tego magazynu zaufanych certyfikatów powinno rozwiązać problem. Możesz odnieść się do mojej odpowiedzi na powiązane pytanie dotyczące uzyskiwania narzędzi do tego celu, ale narzędzie Java Keytool jest do tego wystarczające.

Ostrzeżenie : magazyn zaufanych certyfikatów to zasadniczo lista wszystkich zaufanych urzędów certyfikacji. Jeśli umieścisz certyfikat, który nie należy do urzędu certyfikacji, któremu nie ufasz, połączenia SSL / TLS z witrynami posiadającymi certyfikaty wydane przez tę jednostkę mogą zostać odszyfrowane, jeśli klucz prywatny jest dostępny.

Aktualizacja nr 2: Zrozumienie danych wyjściowych śledzenia JSSE

Magazyn kluczy i zaufane magazyny używane przez maszynę JVM są zwykle wymienione na samym początku, podobnie jak poniżej:

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 :

Jeśli używany jest niewłaściwy magazyn zaufanych certyfikatów, musisz ponownie zaimportować certyfikat serwera do właściwego lub ponownie skonfigurować serwer, aby używał tego wymienionego (niezalecane, jeśli masz wiele maszyn JVM i wszystkie są używane do różnych wymagania).

Jeśli chcesz sprawdzić, czy lista certyfikatów zaufania zawiera wymagane certyfikaty, istnieje sekcja dotycząca tego samego, która zaczyna się jako:

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

Musisz sprawdzić, czy podmiotem jest urząd certyfikacji serwera.

Proces uzgadniania będzie miał kilka istotnych wpisów (musisz znać SSL, aby je szczegółowo zrozumieć, ale w celu debugowania bieżącego problemu wystarczy wiedzieć, że błąd handshake_failure jest zwykle zgłaszany w ServerHello.

1. ClientHello

Seria wpisów zostanie zgłoszona podczas inicjowania połączenia. Pierwszą wiadomością wysłaną przez klienta w konfiguracji połączenia SSL / TLS jest wiadomość ClientHello, zwykle zgłaszana w dziennikach jako:

*** 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 }
***

Zwróć uwagę na używane zestawy szyfrów. Może to być zgodne z wpisem w pliku merchant.properties, ponieważ ta sama konwencja może być stosowana przez bibliotekę banku. Jeśli zastosowana konwencja jest inna, nie ma powodu do zmartwień, ponieważ ServerHello poinformuje o tym, jeśli zestaw szyfrów jest niekompatybilny.

2. ServerHello

Serwer odpowiada za pomocą ServerHello, które wskaże, czy można kontynuować konfigurację połączenia. Wpisy w dziennikach są zwykle następującego typu:

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

Zwróć uwagę na wybrany zestaw szyfrów; jest to najlepszy pakiet dostępny zarówno dla serwera, jak i klienta. Zwykle zestaw szyfrów nie jest określany, jeśli występuje błąd. Certyfikat serwera (i opcjonalnie całego łańcucha) jest wysyłany przez serwer i znajdowałby się we wpisach jako:

*** 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
***

Jeśli weryfikacja certyfikatu powiodła się, znajdziesz wpis podobny do:

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

Jeden z powyższych kroków nie powiódłby się, powodując błąd handshake_failure, ponieważ uzgadnianie jest zwykle zakończone na tym etapie (nie do końca, ale kolejne etapy uzgadniania zwykle nie powodują niepowodzenia uzgadniania). Musisz dowiedzieć się, który krok się nie powiódł, i opublikować odpowiednią wiadomość jako aktualizację pytania (chyba że już zrozumiałeś komunikat i wiesz, co zrobić, aby go rozwiązać).

Vineet Reynolds
źródło
Jeśli możesz, opublikuj, co masz, abyśmy mogli zaktualizować odpowiedź, podając bardziej szczegółową.
Vineet Reynolds
1
Ok Vineet, nie mogę wymyślić, jak sobie z tym poradzić, jestem już wyczerpany. Znalazłem sposób na sprawdzenie adresu URL serwera za pomocą openssl „openssl s_client
-connect nazwa
@hoss, wygląda na to, że certyfikat serwera został wydany przez podmiot, którego nie ma w zaufanym magazynie używanym przez OpenSSL, a także prawdopodobnie nie ma go w zaufanym magazynie używanym przez Twój serwer (klienta), gdy łączy się z serwer. W takim przypadku musisz zaimportować certyfikat urzędu certyfikacji, który wystawił certyfikat ( a nie serwer ) do magazynu zaufanych certyfikatów klienta (OpenSSL / Twój serwer).
Vineet Reynolds
1
Cóż, może polega na cacerts. Ale możesz to ustalić tylko wtedy, gdy rozumiesz wyniki debugowania sieci. Jeśli chcesz to sprawdzić, musisz użyć keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacertspolecenia, aby wydrukować zawartość. Następnie sprawdź, czy certyfikaty w cacerts są zgodne z CA certyfikatu banku.
Vineet Reynolds
5
Wartość domyślna to zwykle changeit. Chyba że został zmieniony.
Vineet Reynolds
20

Zainstalowanie rozszerzenia Java Cryptography Extension (JCE) Unlimited Strength ( dla JDK7 | dla JDK8 ) może naprawić ten błąd. Rozpakuj plik i postępuj zgodnie z plikiem readme, aby go zainstalować.

Simon Yu
źródło
17

Może się to również zdarzyć, gdy klient musi przedstawić certyfikat. Gdy serwer wyświetli łańcuch certyfikatów, mogą się zdarzyć następujące sytuacje:

3. Żądanie certyfikatu Serwer wyśle ​​żądanie certyfikatu od klienta. Żądanie wyświetli listę wszystkich certyfikatów, które akceptuje serwer.

*** 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. Łańcuch certyfikatów klienta Jest to certyfikat, który klient wysyła do serwera.

*** 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

Jeśli w łańcuchu nie ma certyfikatu, a serwer go wymaga, w tym miejscu pojawi się błąd uzgadniania. Prawdopodobną przyczyną jest to, że nie znaleziono ścieżki do Twojego certyfikatu.

5. Weryfikacja certyfikatu Klient prosi serwer o weryfikację certyfikatu 

*** CertificateVerify
... payload of verify check

Ten krok nastąpi tylko wtedy, gdy wysyłasz certyfikat.

6. Zakończone Serwer odpowie weryfikacją

*** Finished
verify_data:  { 345, ... }
Bryg
źródło
w moim przypadku wydaje się, że wszystkie kroki są w porządku, ale nadal pojawia się błąd uzgadniania.
tibi
bardzo ładna odpowiedź ... ale wszystko to jest w porządku w przypadku niepowodzenia uścisku dłoni, ale nadal mam niepowodzenie. czy mógłbyś spojrzeć na moje podobne pytanie?
tibi
Nieprzedstawienie certyfikatu klienta nie jest żadnym błędem w protokole TLS. Jeśli serwer wymaga certyfikatu klienta, a takiego nie ma, zamknie połączenie.
Markiz Lorne
@EJP to prawda, to nie jest błąd w TLS, jednak nieudane połączenie pojawia się jako błąd w kodzie Java.
Brig
1
@Brig Ale nie jako ostrzeżenie, o czym mówi ta odpowiedź i czego dotyczy pytanie.
Markiz Lorne
17

Niepowodzenie uzgadniania może być błędną implementacją protokołu TLSv1.

W naszym przypadku pomogło to w Javie 7: 

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

Jvm będzie negocjować w tej kolejności. Serwery z najnowszą aktualizacją będą działać w wersji 1.2, błędne serwery przejdą do v1 i to działa z podobną wersją 1 w java 7.

Bela Vizy
źródło
1
To mi pomogło. Był mój ClientHello, ale nie było serwera, koniec był dość gwałtowny. Naprawiło to dla mnie w Javie 7. Dziękuję bardzo.
virgo47
16

Nie sądzę, żeby to rozwiązało problem pierwszego pytającego, ale dla pracowników Google przyjeżdżających tutaj po odpowiedzi:

W aktualizacji 51, java 1.8 domyślnie zabronione [1] szyfry RC4, jak widać na stronie z informacjami o wydaniu:

Poprawka: Zabroń zestawów szyfrów RC4

RC4 jest teraz uważane za skompromitowany szyfr.

W implementacji Oracle JSSE usunięto zestawy szyfrowania RC4 zarówno z listy domyślnie włączonych zestawów szyfrowania klienta, jak i serwera. Te zestawy szyfrów można nadal włączać metodami SSLEngine.setEnabledCipherSuites()i SSLSocket.setEnabledCipherSuites(). Zobacz JDK-8077109 (niepubliczne).

Jeśli twój serwer ma silne preferencje dla tego szyfru (lub użyj tylko tego szyfru), może to spowodować wywołanie handshake_failurew java.

Możesz przetestować połączenie z serwerem, włączając szyfry RC4 (najpierw spróbuj bez enabledargumentów, aby zobaczyć, czy wyzwala a handshake_failure, a następnie ustaw 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

motobói
źródło
10

Mam ten błąd podczas próby użycia JDK 1.7. Kiedy zaktualizowałem JDK do jdk1.8.0_66, wszystko zaczęło działać dobrze.

Więc najprostszym rozwiązaniem tego problemu może być - zaktualizuj swój JDK i zacznie działać dobrze.

Maxim Votyakov
źródło
4
Ładny. Najprostszym rozwiązaniem jest aktualizacja JDK? : D Czy wiesz, jak skomplikowane może to być w zależności od środowiska, w którym to się dzieje? Załóżmy, że Amazon uruchomił JDK 7 i musiałby teraz nagle uaktualnić do JDK 8 ... Świetnie!
Arturas M
1
Prosta drobna aktualizacja rozwiązała ten problem. Z JDK 11.0.1 do 11.0.6
Clint,
5

W moim przypadku certyfikat jest importowany, błąd pozostaje, rozwiązany przez dodanie System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3");przed połączeniem

molly gu
źródło
Pracował dla mnie w java 1.8. Dzięki :)
Supun Amarasinghe
4

Znalazłem serwer HTTPS, który zawiódł w ten sposób, jeśli mój proces klienta Java został skonfigurowany z

-Djsse.enableSNIExtension=false

Połączenie nie powiodło się handshake_failurepo ServerHellopomyślnym zakończeniu, ale przed uruchomieniem strumienia danych.

Nie było wyraźnego komunikatu o błędzie, który zidentyfikowałby problem, błąd po prostu wyglądał

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

Wyizolowałem problem, próbując z -Djsse.enableSNIExtension=falseopcją „ ” i bez niej

Bogaty
źródło
Otrzymuję ten sam błąd podczas łączenia się z piaskownicą GDAX, jakieś rozwiązania?
Nitin Vavdiya
1
Rozwiązaniem jest włączenie SNI (usunięcie tej opcji) lub poproszenie administratora serwera zdalnego o włączenie połączeń bez obsługi SNI.
Nux
3

Zakładając, że używasz odpowiednich protokołów SSL / TLS, poprawnie skonfigurowałeś keyStorei trustStorei potwierdziłeś, że nie ma żadnych problemów z samymi certyfikatami, może być konieczne wzmocnienie algorytmów bezpieczeństwa .

Jak wspomniano w odpowiedzi Vineeta , jednym z możliwych powodów otrzymania tego błędu jest użycie niekompatybilnych zestawów szyfrów. Aktualizując moje pliki local_policyi US_export_policyjars w securityfolderze mojego JDK o te dostarczone w rozszerzeniu Java Cryptography Extension (JCE) , udało mi się pomyślnie zakończyć uzgadnianie.

heez
źródło
2

Używam klienta http com.google.api. Kiedy komunikuję się z wewnętrzną witryną firmy, mam ten problem, gdy omyłkowo użyłem https zamiast 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)
thebiggestlebowski
źródło
Nie, nie możesz. Serwer nie może wysłać alertu TLS, jeśli nie mówi TLS.
Markiz Lorne
Zaktualizowałem swój komentarz, aby pokazać dane wyjściowe z mojego programu. To jest prawdziwe. Byłbym wdzięczny, gdybyś usunął głos negatywny.
thebiggestlebowski
Jest prawdziwy, ale nie jest spowodowany komunikacją TLS z serwerem zwykłego tekstu. Serwer z tekstem jawnym z definicji nie obsługuje protokołu TLS i dlatego z definicji nie można otrzymać od niego alertu TLS. Nie masz żadnych informacji o tym, kto zlekceważył Twoją odpowiedź.
Markiz Lorne
Założyłem, że nie zagłosowałeś - przepraszam, jeśli tak nie jest. Mój komunikat o błędzie dokładnie pasuje do tytułu tego pytania. To jest prawidłowa ścieżka / przypadek testowy, aby otrzymać ten komunikat o błędzie i mam rozwiązanie, które może pomóc innym. Z całym szacunkiem, nie sądzę, że ma to znaczenie, czy jest to spowodowane odpowiedzią błędu serwera TLS, czy nie. Ktoś wyląduje tutaj z Google i moja odpowiedź może pomóc, jeśli popełni ten sam błąd.
thebiggestlebowski
Nie powiedziałem nic o twoim komunikacie o błędzie. Komentuję Pańskie nieprawidłowe twierdzenie, że jest to spowodowane „błędnym użyciem protokołu HTTPS zamiast HTTP”. Tak nie jest i nie może być z powodów, które przedstawiłem i do których nie odniosłeś się w żaden sposób. Korzystanie z protokołu HTTP z pewnością sprawi, że zniknie, ponieważ nie ma alertów TLS w zwykłym tekście, ale nie rozwiązuje podstawowego problemu.
Markiz Lorne
2

Dzisiaj spotykam ten sam problem z klientem OkHttp, aby uzyskać adres URL oparty na protokole https. Było to spowodowane niezgodnością wersji protokołu Https i metody szyfrowania pomiędzy serwerem a klientem .

1) sprawdź wersję protokołu https witryny i metodę szyfrowania.

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

Otrzymasz wiele szczegółowych informacji, najważniejsze informacje są wymienione w następujący sposób:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
2) Skonfiguruj klienta http, na przykład w przypadku klienta 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();
    }
}

To dostanie to, czego chcemy.

Armstrongya
źródło
1

Mój był TLSbłąd niezgodnej wersji.

Wcześniej to TLSv1zmieniłem, TLSV1.2co rozwiązało mój problem.

Ali786
źródło
1

Miałem podobny problem; aktualizacja do Apache HTTPClient 4.5.3 naprawiła to.

Hazel Troost
źródło
1

Ugg! Okazało się, że był to po prostu problem z wersją Javy. Otrzymałem błąd uścisku dłoni przy użyciu JRE 1.6 i wszystko działało idealnie z JRE 1.8.0_144.

Jan
źródło
0

Zastrzeżenie: nie wiem, czy odpowiedź będzie pomocna dla wielu osób, po prostu udostępniam, ponieważ może.

Otrzymałem ten błąd podczas używania Parasoft SOATest do wysyłania żądania XML (SOAP).

Problem polegał na tym, że po dodaniu certyfikatu i uwierzytelnieniu go wybrałem zły alias z listy rozwijanej.

user3251882
źródło
0

W moim przypadku witryna może po prostu używać TLSv1.2. i używam apache httpclient 4.5.6, używam tego kodu i instaluję jce, aby rozwiązać ten problem (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

kod:

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();
Tianmu
źródło
0

Aby rozwiązać problemy z perspektywy programisty (punkt 1) i administratora systemu (punkty 2 i 3):

  1. Włącz debugowanie uzgadniania SSL w Javie za pośrednictwem -Djavax.net.debug=ssl:handshake:verbose.
  2. Zainstaluj ssldump na serwerze przez sudo apt install ssldumplub skompiluj ze źródła, podążając za tym linkiem, jeśli zauważysz Unknown valuew szyfrowaniu po uruchomieniu poniższego kroku.
  3. Na serwerze sudo ssldump -k <your-private-key> -i <your-network-interface>
  4. Sprawdź w dzienniku prawdziwą przyczynę niepowodzenia.

Przykład niedziałającego uzgadniania dziennika 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

Przykład udanego uzgadniania dziennika 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

Przykład niedziałającego dziennika 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"
}
)
Lee Chee Kiam
źródło
0

W moim przypadku miałem jeden problem z wersją 1.1. Z łatwością odtworzyłem problem za pomocą curl. Serwer nie obsługiwał niższych wersji niż TLS1.2.

Ten problem z uściskiem dłoni:

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

W wersji 1.2 działało dobrze:

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

Na serwerze działał Weblogic i dodanie tego argumentu w setEnvDomain.sh sprawiło, że działał z TLSv1.1:

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1
ravenskater
źródło
0

Ten problem występuje z powodu wersji Java. Używałem JDK 1.8.0.231 i otrzymałem ten błąd. Zdegradowałem moją wersję javy z 1.8.0.231 do 1.8.0.171, teraz działa dobrze.

hariom gupta
źródło