Schwerwiegende Warnung erhalten: handshake_failure über SSLHandshakeException

134

Ich habe ein Problem mit der autorisierten SSL-Verbindung. Ich habe eine Struts-Aktion erstellt, die mit einem vom Client autorisierten SSL-Zertifikat eine Verbindung zu einem externen Server herstellt. In meiner Aktion versuche ich, einige Daten an den Bankserver zu senden, aber ohne Glück, da ich vom Server den folgenden Fehler habe:

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

Meine Methode aus meiner Aktionsklasse, die Daten an den Server sendet

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

Meine Merchant.properties-Datei:

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

Zum ersten Mal dachte ich, dass dies ein Zertifikatsproblem ist. Ich habe es von .pfx in .jks konvertiert, aber ich habe den gleichen Fehler ohne Änderungen.

Denees
quelle
Haben Sie das SSL-Zertifikat des Servers zu Ihrem Truststore hinzugefügt?
Happymeal
Entschuldigung, ich verstehe nicht, was das bedeutet. Ich bin neu in SSL
Denees
Ich gehe davon aus, dass Ihre App den Java-Standard-Truststore verwendet. Der Standard-Truststore ist <java-home> / lib / security / cacerts. Öffnen Sie die URL des Servers mit Ihrem Browser und laden Sie alle SSL-Zertifikate herunter. einschließlich etwaiger Ketten- / Zwischenzertifikate. Fügen Sie dann alle diese Zertifikate zum Truststore hinzu.
Happymeal
Ich kann die URL im Browser nicht öffnen, da ich aufgrund des Clientauthentifizierungszertifikats nur bestimmte Parameter an diesen Link senden kann, die ich von Clients erhalte.
Denees
Öffne einfach die URL. Ignorieren Sie alle Fehler, die Sie in Ihrem Browser sehen. Wenn Sie auf die URL zugreifen, sollte in der Adressleiste Ihres Browsers ein Vorhängeschlosssymbol angezeigt werden. Klicken Sie darauf und laden Sie das SSL-Zertifikat des Servers herunter.
Happymeal

Antworten:

251

Der Handshake-Fehler kann verschiedene Ursachen haben:

  • Inkompatible Cipher Suites, die vom Client und vom Server verwendet werden. Dies würde erfordern, dass der Client eine vom Server unterstützte Verschlüsselungssuite verwendet (oder aktiviert).
  • Inkompatible Versionen von SSL werden verwendet (der Server akzeptiert möglicherweise nur TLS v1, während der Client nur SSL v3 verwenden kann). Auch hier muss der Client möglicherweise sicherstellen, dass er eine kompatible Version des SSL / TLS-Protokolls verwendet.
  • Unvollständiger Vertrauenspfad für das Serverzertifikat; Das Zertifikat des Servers wird vom Client wahrscheinlich nicht als vertrauenswürdig eingestuft. Dies würde normalerweise zu einem ausführlicheren Fehler führen, ist aber durchaus möglich. Normalerweise besteht das Update darin, das CA-Zertifikat des Servers in den Trust Store des Clients zu importieren.
  • Das Zertifikat wird für eine andere Domain ausgestellt. Auch dies hätte zu einer ausführlicheren Meldung geführt, aber ich werde das Update hier angeben, falls dies die Ursache ist. Die Lösung in diesem Fall wäre, den Server (es scheint nicht Ihr Server zu sein) dazu zu bringen, das richtige Zertifikat zu verwenden.

Da der zugrunde liegende Fehler nicht lokalisiert werden kann, ist es besser, das -Djavax.net.debug=allFlag einzuschalten, um das Debuggen der hergestellten SSL-Verbindung zu ermöglichen. Bei eingeschaltetem Debug können Sie feststellen, welche Aktivität im Handshake fehlgeschlagen ist.

Aktualisieren

Basierend auf den jetzt verfügbaren Details scheint das Problem auf einen unvollständigen Zertifikatvertrauenspfad zwischen dem an den Server ausgestellten Zertifikat und einer Stammzertifizierungsstelle zurückzuführen zu sein. In den meisten Fällen liegt dies daran, dass das Zertifikat der Stammzertifizierungsstelle im Vertrauensspeicher nicht vorhanden ist, was dazu führt, dass kein Zertifikatvertrauenspfad vorhanden sein kann. Das Zertifikat ist vom Kunden im Wesentlichen nicht vertrauenswürdig. Browser können eine Warnung anzeigen , damit Benutzer dies ignorieren können. Dies gilt jedoch nicht für SSL-Clients (wie die HttpsURLConnection- Klasse oder eine HTTP-Client-Bibliothek wie Apache HttpComponents Client ).

Die meisten dieser Clientklassen / -bibliotheken würden sich auf den Vertrauensspeicher stützen, der von der JVM für die Zertifikatvalidierung verwendet wird. In den meisten Fällen ist dies die cacertsDatei im Verzeichnis JRE_HOME / lib / security. Wenn der Speicherort des Vertrauensspeichers mithilfe der JVM-Systemeigenschaft angegeben wurde javax.net.ssl.trustStore, wird der Speicher in diesem Pfad normalerweise von der Clientbibliothek verwendet. Wenn Sie Zweifel haben, schauen Sie sich Ihre MerchantKlasse an und finden Sie heraus, mit welcher Klasse / Bibliothek die Verbindung hergestellt wird.

Durch Hinzufügen der Zertifikatzertifizierungsstelle des Servers zu diesem Vertrauensspeicher sollte das Problem behoben werden. Sie können sich auf meine Antwort zu einer verwandten Frage zum Abrufen von Tools für diesen Zweck beziehen , aber das Java-Dienstprogramm keytool ist für diesen Zweck ausreichend.

Warnung : Der Trust Store ist im Wesentlichen die Liste aller CAs, denen Sie vertrauen. Wenn Sie ein Zertifikat eingeben, das nicht zu einer Zertifizierungsstelle gehört, der Sie nicht vertrauen, können SSL / TLS-Verbindungen zu Sites mit von dieser Entität ausgestellten Zertifikaten entschlüsselt werden, wenn der private Schlüssel verfügbar ist.

Update Nr. 2: Grundlegendes zur Ausgabe des JSSE-Trace

Der Keystore und die von der JVM verwendeten Truststores werden normalerweise ganz am Anfang aufgelistet, ähnlich wie folgt:

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 : 

Wenn der falsche Truststore verwendet wird, müssen Sie das Serverzertifikat erneut in das richtige Zertifikat importieren oder den Server für die Verwendung des aufgelisteten Zertifikats neu konfigurieren (nicht empfohlen, wenn Sie mehrere JVMs haben und alle für unterschiedliche verwendet werden Bedürfnisse).

Wenn Sie überprüfen möchten, ob die Liste der Vertrauenszertifikate die erforderlichen Zertifikate enthält, gibt es einen Abschnitt dafür, der wie folgt beginnt:

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

Sie müssen suchen, ob die Zertifizierungsstelle des Servers ein Thema ist.

Der Handshake-Prozess enthält einige wichtige Einträge (Sie müssen SSL kennen, um sie im Detail zu verstehen. Zum Debuggen des aktuellen Problems reicht es jedoch aus zu wissen, dass ein handshake_failure normalerweise im ServerHello gemeldet wird.

1. ClientHallo

Eine Reihe von Einträgen wird gemeldet, wenn die Verbindung initialisiert wird. Die erste vom Client in einem SSL / TLS-Verbindungsaufbau gesendete Nachricht ist die ClientHello-Nachricht, die normalerweise in den Protokollen wie folgt gemeldet wird:

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

Beachten Sie die verwendeten Cipher Suites. Dies muss möglicherweise mit dem Eintrag in Ihrer Merchant.properties-Datei übereinstimmen , da dieselbe Konvention möglicherweise von der Bibliothek der Bank verwendet wird. Wenn die verwendete Konvention anders ist, besteht kein Grund zur Sorge, da ServerHello dies angibt, wenn die Verschlüsselungssuite nicht kompatibel ist.

2. ServerHallo

Der Server antwortet mit einem ServerHello, das angibt, ob der Verbindungsaufbau fortgesetzt werden kann. Einträge in den Protokollen sind normalerweise vom folgenden Typ:

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

Beachten Sie die ausgewählte Chiffresuite. Dies ist die beste Suite, die sowohl dem Server als auch dem Client zur Verfügung steht. Normalerweise wird die Verschlüsselungssuite nicht angegeben, wenn ein Fehler auftritt. Das Zertifikat des Servers (und optional der gesamten Kette) wird vom Server gesendet und befindet sich in den Einträgen wie folgt:

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

Wenn die Überprüfung des Zertifikats erfolgreich war, finden Sie einen Eintrag ähnlich dem folgenden:

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

Einer der oben genannten Schritte wäre nicht erfolgreich gewesen, was zu einem Handshake-Fehler geführt hätte, da der Handshake in dieser Phase normalerweise abgeschlossen ist (nicht wirklich, aber die nachfolgenden Phasen des Handshakes verursachen normalerweise keinen Handshake-Fehler). Sie müssen herausfinden, welcher Schritt fehlgeschlagen ist, und die entsprechende Nachricht als Aktualisierung der Frage veröffentlichen (es sei denn, Sie haben die Nachricht bereits verstanden und wissen, wie Sie sie beheben können).

Vineet Reynolds
quelle
Bitte posten Sie alles, was Sie haben, wenn Sie können, damit ich die Antwort mit einer spezifischeren aktualisieren kann.
Vineet Reynolds
1
Ok Vineet, ich kann nicht herausfinden, wie ich damit umgehen soll, ich bin bereits erschöpft. Ich habe eine Möglichkeit gefunden, die Server-URL mit openssl "openssl s_client -connect Servername: 4402" zu überprüfen und zu sehen, was ich habe: img225.imageshack.us/img225/8999/screenshoturr.png
Denees
@hoss, es sieht so aus, als ob das Zertifikat des Servers von einer Entität ausgestellt wurde, die nicht in dem von OpenSSL verwendeten Trust Store und möglicherweise auch nicht in dem von Ihrem Server (dem Client) verwendeten Trust Store vorhanden ist , wenn eine Verbindung hergestellt wird der Kellner. In diesem Fall müssen Sie das Zertifikat der Zertifizierungsstelle, die das Zertifikat ausgestellt hat ( und nicht den Server ), in den Trust Store Ihres Clients (OpenSSL / Ihr Server) importieren .
Vineet Reynolds
1
Nun, vielleicht ist es auf Cacerts angewiesen. Sie können dies jedoch nur feststellen, wenn Sie die Ausgabe des Netzwerk-Debugs verstehen. Wenn Sie dies überprüfen möchten, müssen Sie den keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacertsBefehl verwenden, um den Inhalt auszudrucken. Überprüfen Sie anschließend, ob die Zertifikate in den Zertifikaten mit der Zertifizierungsstelle des Bankzertifikats übereinstimmen.
Vineet Reynolds
5
Der Standardwert ist normalerweise changeit. Es sei denn, es wurde geändert.
Vineet Reynolds
20

Durch die Installation der unbegrenzten Stärke der Java Cryptography Extension (JCE) ( für JDK7 | für JDK8 ) kann dieser Fehler möglicherweise behoben werden . Entpacken Sie die Datei und folgen Sie der Readme-Datei, um sie zu installieren.

Simon Yu
quelle
16

Der Handshake-Fehler kann eine fehlerhafte Implementierung des TLSv1-Protokolls sein.

In unserem Fall hat dies bei Java 7 geholfen:

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

Das JVM wird in dieser Reihenfolge verhandeln. Die Server mit dem neuesten Update werden 1.2 ausführen, die fehlerhaften Server werden auf Version 1 heruntergefahren und das funktioniert mit der ähnlichen Version 1 in Java 7.

Bela Vizy
quelle
1
Das hat mir geholfen. Es gab mein ClientHello, aber keinen Server, das Ende war ziemlich abrupt. Dies hat es für mich auf Java 7 behoben. Vielen Dank.
Jungfrau47
15

Dies kann auch passieren, wenn der Client ein Zertifikat vorlegen muss. Nachdem der Server die Zertifikatkette aufgelistet hat, kann Folgendes passieren:

3. Zertifikatanforderung Der Server gibt eine Zertifikatanforderung vom Client aus. Die Anforderung listet alle Zertifikate auf, die der Server akzeptiert.

*** 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. Client-Zertifikatkette Dies ist das Zertifikat, das der Client an den Server sendet.

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

Wenn die Kette kein Zertifikat enthält und der Server eines benötigt, wird hier der Handshake-Fehler angezeigt. Eine wahrscheinliche Ursache ist, dass der Pfad zu Ihrem Zertifikat nicht gefunden wurde.

5. Zertifikatüberprüfung Der Client fordert den Server auf, das Zertifikat zu überprüfen

*** CertificateVerify
... payload of verify check

Dieser Schritt wird nur ausgeführt, wenn Sie ein Zertifikat senden.

6. Fertig Der Server antwortet mit einer Bestätigungsantwort

*** Finished
verify_data:  { 345, ... }
Brigg
quelle
In meinem Fall scheinen alle Schritte in Ordnung zu sein, aber es wird immer noch der Handshake-Fehler angezeigt.
Tibi
sehr schöne Antwort ... aber all dies ist in Ordnung bei meinem Handschlagfehler, aber ich habe immer noch den Fehler. Könnten Sie sich meine ähnliche Frage ansehen?
Tibi
Das Versäumnis, ein Client-Zertifikat vorzulegen, ist kein Fehler in TLS. Wenn der Server ein Client-Zertifikat benötigt und eines nicht vorgelegt wird, wird die Verbindung geschlossen.
Marquis von Lorne
@EJP das stimmt, es ist kein Fehler in TLS, aber die fehlgeschlagene Verbindung wird als Fehler im Java-Code angezeigt.
Brig
1
@Brig Aber nicht als Warnung, was diese Antwort sagt und worum es bei der Frage geht.
Marquis von Lorne
15

Ich denke nicht, dass dies das Problem für den ersten Fragesteller löst, sondern für Googler, die hierher kommen, um Antworten zu erhalten:


Bei Update 51 verbot Java 1.8 standardmäßig [1] RC4-Chiffren, wie auf der Seite mit den Versionshinweisen zu sehen ist:

Fehlerbehebung: RC4-Verschlüsselungssuiten verbieten

RC4 wird jetzt als kompromittierte Chiffre betrachtet.

RC4-Verschlüsselungssuiten wurden in der Oracle JSSE-Implementierung sowohl aus der Liste der standardmäßig aktivierten Client- als auch Serververschlüsselungssuiten entfernt. Diese Cipher Suites können weiterhin mit SSLEngine.setEnabledCipherSuites()und SSLSocket.setEnabledCipherSuites()Methoden aktiviert werden. Siehe JDK-8077109 (nicht öffentlich).

Wenn Ihr Server diese Verschlüsselung stark bevorzugt (oder nur diese Verschlüsselung verwendet), kann dies ein handshake_failureOn-Java auslösen .

Sie können die Verbindung zum Server testen, um RC4-Chiffren zu aktivieren (versuchen Sie zunächst ohne enabledArgument, festzustellen, ob a ausgelöst wird handshake_failure, und setzen Sie dann 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/de/download/faq/release_changes.xml

motobói
quelle
10

Ich habe diesen Fehler, als ich versucht habe, JDK 1.7 zu verwenden. Als ich mein JDK auf jdk1.8.0_66 aktualisierte, funktionierte alles einwandfrei.

Die einfachste Lösung für dieses Problem könnte also sein: Aktualisieren Sie Ihr JDK und es könnte gut funktionieren.

Maxim Votyakov
quelle
4
Nett. Die einfachste Lösung ist das Upgrade von JDK? : D Wissen Sie, wie kompliziert das sein kann, abhängig von der Umgebung, in der dies durchgeführt wird? Angenommen, Amazon hat JDK 7 ausgeführt und müsste jetzt plötzlich auf JDK 8 aktualisieren ... Schön!
Arturas M
1
Ein einfaches kleines Versions-Upgrade hat dieses Problem für mich behoben. Von JDK 11.0.1 auf 11.0.6
Clint
4

In meinem Fall wird cert importiert, der Fehler bleibt bestehen und wird durch Hinzufügen System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3");vor dem Verbinden behoben

Molly Gu
quelle
Arbeitete für mich in Java 1.8. Danke :)
Supun Amarasinghe
3

Angenommen, Sie verwenden die richtigen SSL / TLS-Protokolle, haben Ihr keyStoreund ordnungsgemäß konfiguriert trustStoreund bestätigt, dass keine Probleme mit den Zertifikaten selbst vorliegen, müssen Sie möglicherweise Ihre Sicherheitsalgorithmen stärken .

Wie in der Antwort von Vineet erwähnt , ist ein möglicher Grund, warum Sie diesen Fehler erhalten, die Verwendung inkompatibler Chiffresuiten. Durch Aktualisieren von my local_policyund US_export_policyjars im securityOrdner meines JDK mit denen in der Java Cryptography Extension (JCE) konnte ich den Handshake erfolgreich abschließen.

heez
quelle
2

Ich habe heute das gleiche Problem mit dem OkHttp-Client, um eine https-basierte URL zu erhalten. Dies wurde durch die Nichtübereinstimmung der HTTP-Protokollversion und der Cipher-Methode zwischen Server- und Client-Seite verursacht .

1) Überprüfen Sie die https-Protokollversion und die Verschlüsselungsmethode Ihrer Website.

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

Sie erhalten viele Detailinformationen, die wichtigsten Informationen sind wie folgt aufgeführt:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
2) Konfigurieren Sie Ihren http-Client beispielsweise im Fall eines OkHttp-Clients :
@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();
    }
}

Dies wird bekommen, was wir wollen.

Armstrongya
quelle
2

Ich habe einen HTTPS-Server gefunden, der auf diese Weise fehlgeschlagen ist, wenn mein Java-Client-Prozess mit konfiguriert wurde

-Djsse.enableSNIExtension=false

Die Verbindung schlug fehl, handshake_failurenachdem die ServerHelloerfolgreich beendet wurde, aber bevor der Datenstrom gestartet wurde.

Es gab keine eindeutige Fehlermeldung, die das Problem identifizierte. Der Fehler sah einfach so aus

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

Ich habe das Problem isoliert, indem ich es mit und ohne die -Djsse.enableSNIExtension=falseOption " " versucht habe

Reich
quelle
Ich erhalte den gleichen Fehler beim Herstellen einer Verbindung zur GDAX-Sandbox. Gibt es Lösungen dafür?
Nitin Vavdiya
1

Meins war ein TLSinkompatibler Versionsfehler.

Zuvor habe TLSv1ich es geändert, um TLSV1.2mein Problem zu lösen.

Ali786
quelle
1

Ich verwende den http-Client com.google.api. Wenn ich mit einer internen Unternehmenswebsite kommuniziere, tritt dieses Problem auf, wenn ich versehentlich https anstelle von http verwendet habe.

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
quelle
Nein, kannst du nicht. Der Server kann keine TLS-Warnung senden, wenn er kein TLS spricht.
Marquis von Lorne
Ich habe meinen Kommentar aktualisiert, um die Ausgabe meines Programms anzuzeigen. Das ist echt. Würde mich freuen, wenn Sie die Abwahl entfernen würden.
Thebiggestlebowski
Es ist real, wird aber nicht dadurch verursacht, dass TLS mit einem Klartextserver gesprochen wird. Ein Klartextserver spricht per Definition nicht über TLS, und Sie können daher per Definition möglicherweise keine TLS-Warnung von ihm erhalten. Sie haben keine Informationen darüber, wer Ihre Antwort abgelehnt hat.
Marquis von Lorne
Ich nahm an, Sie haben abgestimmt - ich entschuldige mich, wenn das nicht der Fall ist. Meine Fehlermeldung stimmt genau mit dem Titel dieser Frage überein. Es ist ein gültiger Pfad / Testfall, um diese Fehlermeldung zu erhalten, und ich habe eine Lösung, die anderen helfen könnte. Ich denke nicht, dass es wichtig ist, ob es durch eine TLS-Server-Fehlerantwort verursacht wird oder nicht. Jemand wird hier von Google landen und meine Antwort könnte helfen, wenn er den gleichen Fehler gemacht hat.
Thebiggestlebowski
Ich habe nichts über Ihre Fehlermeldung gesagt. Ich kommentiere Ihre falsche Behauptung, dass sie auf "irrtümliche Verwendung von HTTPS anstelle von HTTP" zurückzuführen ist. Es ist nicht und kann es auch nicht sein, aus Gründen, die ich angegeben habe und die Sie in keiner Weise angesprochen haben. Die Verwendung von HTTP wird es sicherlich verschwinden lassen, da es im Klartext keine TLS-Warnungen gibt, das zugrunde liegende Problem jedoch nicht behoben wird.
Marquis von Lorne
1

Ich hatte ein ähnliches Problem. Ein Upgrade auf Apache HTTPClient 4.5.3 hat das Problem behoben.

Hazel Troost
quelle
1

Ugg! Es stellte sich heraus, dass dies für mich einfach ein Problem mit der Java-Version war. Ich habe den Handshake-Fehler mit JRE 1.6 erhalten und mit JRE 1.8.0_144 hat alles perfekt funktioniert.

John
quelle
0

Haftungsausschluss: Mir ist nicht bekannt, ob die Antwort für viele Menschen hilfreich sein wird, nur weil sie es könnte.

Ich habe diesen Fehler erhalten, als ich Parasoft SOATest zum Senden von Anforderungs-XML (SOAP) verwendet habe.

Das Problem war, dass ich den falschen Alias aus der Dropdown-Liste ausgewählt hatte, nachdem ich das Zertifikat hinzugefügt und authentifiziert hatte.

user3251882
quelle
0

In meinem Fall kann die Website nur TLSv1.2 verwenden. und ich benutze Apache httpclient 4.5.6, ich benutze diesen Code und installiere jce, um dies zu lösen (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

Code:

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
quelle
0

So beheben Sie Fehler aus Sicht des Entwicklers (Punkt 1) und des Systemadministrators (Punkt 2 und 3):

  1. Aktivieren Sie das SSL-Handshake-Debugging in Java über -Djavax.net.debug=ssl:handshake:verbose.
  2. Installieren Sie ssldump auf dem Server über sudo apt install ssldumpoder kompilieren Sie aus dem Quellcode, indem Sie diesem Link folgen , wenn Sie dies beobachtenUnknown value beim Ausführen des folgenden Schritts eine .
  3. Auf dem Server sudo ssldump -k <your-private-key> -i <your-network-interface>
  4. Überprüfen Sie das Protokoll über den tatsächlichen Grund des Fehlers.

Beispiel für einen nicht funktionierenden Handshake des ssldump-Protokolls:

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

Beispiel für einen erfolgreichen Handshake des ssldump-Protokolls

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

Beispiel für ein nicht funktionierendes Java-Protokoll

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
quelle
0

In meinem Fall hatte ich ein Problem mit der Version 1.1. Ich habe das Problem leicht mit Locken reproduziert. Der Server unterstützte keine niedrigeren Versionen als TLS1.2.

Dies erhielt ein Handshake-Problem:

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

Mit Version 1.2 hat es gut funktioniert:

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

Auf dem Server wurde ein Weblogic ausgeführt, und durch Hinzufügen dieses Arguments in setEnvDomain.sh konnte TLSv1.1 verwendet werden:

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1
Ravenskater
quelle
0

Dieses Problem tritt aufgrund der Java-Version auf. Ich habe 1.8.0.231 JDK verwendet und diesen Fehler erhalten. Ich habe meine Java-Version von 1.8.0.231 auf 1.8.0.171 herabgesetzt. Jetzt funktioniert es einwandfrei.

Hariom Gupta
quelle