Réception d'une alerte fatale: handshake_failure via SSLHandshakeException

134

J'ai un problème avec la connexion SSL autorisée. J'ai créé Struts Action qui se connecte au serveur externe avec un certificat SSL autorisé par le client. Dans mon action, j'essaie d'envoyer des données au serveur de la banque mais sans aucune chance, car j'ai à la suite du serveur l'erreur suivante:

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

Ma méthode de ma classe Action qui envoie des données au serveur

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

Mon fichier 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

Pour la première fois, j'ai pensé qu'il s'agissait d'un problème de certificat, je l'ai converti de .pfx en .jks, mais j'ai la même erreur, sans changement.

Denees
la source
avez-vous ajouté le certificat ssl du serveur à votre truststore?
happymeal
désolé, je ne comprends pas ce que cela signifie, je suis nouveau sur SSL
Denees
Je suppose que votre application utilise le truststore java par défaut. Le truststore par défaut est <java-home> / lib / security / cacerts. ouvrez l'url du serveur avec votre navigateur et téléchargez tous les certificats ssl; y compris toute chaîne / certificats intermédiaires. puis ajoutez tous ces certificats au truststore.
happymeal
Je ne peux pas ouvrir l'url dans le navigateur, en raison du certificat d'authentification du client, je ne peux envoyer à ce lien que des paramètres spécifiques que j'obtiens des clients.
Denees
ouvrez simplement l'url. ignorez toutes les erreurs que vous voyez sur votre navigateur. lorsque vous accédez à l'url, vous devriez voir une icône de cadenas dans la barre d'adresse de votre navigateur. cliquez dessus et téléchargez le certificat ssl du serveur.
happymeal

Réponses:

252

L'échec de la poignée de main peut s'être produit pour diverses raisons:

  • Suites de chiffrement incompatibles utilisées par le client et le serveur. Cela nécessiterait que le client utilise (ou active) une suite de chiffrement prise en charge par le serveur.
  • Versions incompatibles de SSL en cours d'utilisation (le serveur peut n'accepter que TLS v1, tandis que le client ne peut utiliser que SSL v3). Encore une fois, le client devra peut-être s'assurer qu'il utilise une version compatible du protocole SSL / TLS.
  • Chemin de confiance incomplet pour le certificat de serveur; le certificat du serveur n'est probablement pas approuvé par le client. Cela entraînerait généralement une erreur plus verbeuse, mais c'est tout à fait possible. Habituellement, le correctif consiste à importer le certificat CA du serveur dans le magasin de confiance du client.
  • Le certificat est délivré pour un domaine différent. Encore une fois, cela aurait abouti à un message plus détaillé, mais je vais indiquer le correctif ici au cas où cela serait la cause. La résolution dans ce cas serait de demander au serveur (il ne semble pas être le vôtre) d'utiliser le bon certificat.

Étant donné que l'échec sous-jacent ne peut pas être identifié, il est préférable d'activer l' -Djavax.net.debug=allindicateur pour activer le débogage de la connexion SSL établie. Avec le débogage activé, vous pouvez identifier quelle activité de la poignée de main a échoué.

Mettre à jour

Sur la base des détails désormais disponibles, il semble que le problème soit dû à un chemin d'accès de confiance de certificat incomplet entre le certificat émis vers le serveur et une autorité de certification racine. Dans la plupart des cas, cela est dû au fait que le certificat de l'autorité de certification racine est absent du magasin de confiance, ce qui conduit à la situation dans laquelle un chemin de confiance de certificat ne peut pas exister; le certificat n'est essentiellement pas approuvé par le client. Les navigateurs peuvent présenter un avertissement afin que les utilisateurs puissent l'ignorer, mais il n'en est pas de même pour les clients SSL (comme la classe HttpsURLConnection , ou toute bibliothèque client HTTP comme Apache HttpComponents Client ).

La plupart de ces classes / bibliothèques clientes reposent sur le magasin de confiance utilisé par la machine virtuelle Java pour la validation des certificats. Dans la plupart des cas, ce sera le cacertsfichier dans le répertoire JRE_HOME / lib / security. Si l'emplacement du magasin de confiance a été spécifié à l'aide de la propriété système JVM javax.net.ssl.trustStore, le magasin de ce chemin est généralement celui utilisé par la bibliothèque cliente. En cas de doute, jetez un œil à votre Merchantclasse et déterminez la classe / bibliothèque qu'elle utilise pour établir la connexion.

L'ajout du certificat du serveur émettant l'autorité de certification à ce magasin de confiance devrait résoudre le problème. Vous pouvez vous référer à ma réponse sur une question connexe sur l'obtention d'outils à cet effet, mais l' utilitaire Java keytool est suffisant à cet effet.

Avertissement : le magasin de confiance est essentiellement la liste de toutes les autorités de certification auxquelles vous faites confiance. Si vous insérez un certificat qui n'appartient pas à une autorité de certification à laquelle vous ne faites pas confiance, les connexions SSL / TLS aux sites disposant de certificats émis par cette entité peuvent être déchiffrées si la clé privée est disponible.

Mise à jour n ° 2: Comprendre la sortie de la trace JSSE

Le keystore et les truststores utilisés par la JVM sont généralement répertoriés au tout début, un peu comme suit:

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 : 

Si le mauvais truststore est utilisé, vous devrez réimporter le certificat du serveur dans le bon, ou reconfigurer le serveur pour utiliser celui répertorié (non recommandé si vous avez plusieurs JVM, et tous sont utilisés pour différents Besoins).

Si vous souhaitez vérifier si la liste des certificats de confiance contient les certificats requis, il existe une section pour le même, qui commence par:

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

Vous devrez rechercher si l'autorité de certification du serveur est un sujet.

Le processus de prise de contact aura quelques entrées importantes (vous aurez besoin de connaître SSL pour les comprendre en détail, mais dans le but de déboguer le problème actuel, il suffira de savoir qu'un handshake_failure est généralement signalé dans ServerHello.

1. ClientHello

Une série d'entrées sera signalée lorsque la connexion est en cours d'initialisation. Le premier message envoyé par le client dans une configuration de connexion SSL / TLS est le message ClientHello, généralement signalé dans les journaux comme:

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

Notez les suites de chiffrement utilisées. Cela devra peut-être être conforme à l'entrée de votre fichier merchant.properties, car la même convention pourrait être utilisée par la bibliothèque de la banque. Si la convention utilisée est différente, il n'y a pas de raison de s'inquiéter, car ServerHello l'indiquera si la suite de chiffrement est incompatible.

2. ServerHello

Le serveur répond avec un ServerHello, qui indiquera si la configuration de la connexion peut se poursuivre. Les entrées dans les journaux sont généralement du type suivant:

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

Notez la suite de chiffrement qu'il a choisie; c'est la meilleure suite disponible pour le serveur et le client. En général, la suite de chiffrement n'est pas spécifiée en cas d'erreur. Le certificat du serveur (et éventuellement la chaîne entière) est envoyé par le serveur, et se trouverait dans les entrées sous la forme:

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

Si la vérification du certificat a réussi, vous trouverez une entrée similaire à:

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

L'une des étapes ci-dessus n'aurait pas réussi, ce qui aurait abouti à handshake_failure, car la prise de contact est généralement terminée à ce stade (pas vraiment, mais les étapes suivantes de la prise de contact ne provoquent généralement pas d'échec de la prise de contact). Vous devrez déterminer quelle étape a échoué et publier le message approprié en tant que mise à jour de la question (sauf si vous avez déjà compris le message et que vous savez quoi faire pour le résoudre).

Vineet Reynolds
la source
Veuillez poster ce que vous avez, si vous le pouvez, afin que je puisse mettre à jour la réponse avec une réponse plus précise.
Vineet Reynolds
1
Ok Vineet, je ne sais pas comment y faire face, je suis déjà épuisé. J'ai trouvé un moyen de vérifier l'URL du serveur avec openssl "openssl s_client -connect servername: 4402", et regardez ce que j'ai obtenu: img225.imageshack.us/img225/8999/screenshoturr.png
Denees
@hoss, il semble que le certificat du serveur a été émis par une entité qui n'est pas présente dans le magasin de confiance utilisé par OpenSSL, et également peut-être pas présent dans le magasin de confiance utilisé par votre serveur (le client), lorsqu'il se connecte à le serveur. Dans ce cas, vous devrez importer le certificat de l'autorité de certification qui a émis le certificat ( et non le serveur ) dans le magasin de confiance de votre client (OpenSSL / votre serveur).
Vineet Reynolds
1
Eh bien, peut-être que cela dépend des cacerts. Mais vous ne pouvez le déterminer que si vous comprenez la sortie du débogage réseau. Si vous souhaitez vérifier cela, vous devrez utiliser la keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacertscommande pour imprimer le contenu. Vérifiez ensuite si les certificats dans cacerts correspondent à l'autorité de certification du certificat de la banque.
Vineet Reynolds
5
La valeur par défaut est généralement changeit. À moins que cela ne soit changé.
Vineet Reynolds
20

L'installation de Java Cryptography Extension (JCE) Unlimited Strength ( pour JDK7 | pour JDK8 ) peut résoudre ce bogue. Décompressez le fichier et suivez le readme pour l'installer.

Simon Yu
la source
16

L'échec de la négociation peut être une implémentation du protocole TLSv1 boguée.

Dans notre cas, cela a aidé avec java 7:

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

Le jvm négociera dans cet ordre. Les serveurs avec la dernière mise à jour feront 1.2, les bogués passeront à la v1 et cela fonctionne avec la v1 similaire en java 7.

Bela Vizy
la source
1
Cela m'a aidé. Il y avait mon ClientHello, mais pas de serveur, la fin a été assez abrupte. Cela a résolu le problème pour moi sur Java 7. Merci beaucoup.
virgo47
15

Cela peut également se produire lorsque le client doit présenter un certificat. Une fois que le serveur a répertorié la chaîne de certificats, les événements suivants peuvent se produire:

3. Demande de certificat Le serveur émettra une demande de certificat à partir du client. La demande listera tous les certificats acceptés par le serveur.

*** 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. Chaîne de certificat client Il s'agit du certificat que le client envoie au serveur.

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

S'il n'y a pas de certificat dans la chaîne et que le serveur en a besoin, vous obtiendrez l'erreur d'établissement de liaison ici. Une cause probable est que le chemin d'accès à votre certificat n'a pas été trouvé.

5. Vérification du certificat Le client demande au serveur de vérifier le certificat

*** CertificateVerify
... payload of verify check

Cette étape ne se produira que si vous envoyez un certificat.

6. Terminé Le serveur répondra avec une réponse de vérification

*** Finished
verify_data:  { 345, ... }
Brick
la source
dans mon cas, il semble que toutes les étapes sont correctes mais obtiennent toujours l'erreur de poignée de main.
tibi
très belle réponse ... mais tout cela est ok dans mon échec de poignée de main mais j'ai toujours l'échec. pourriez-vous jeter un oeil à ma question similaire?
tibi le
Le fait de ne pas présenter un certificat client n'est en aucun cas une erreur dans TLS. Si le serveur requiert un certificat client et qu'aucun n'est présenté, il fermera la connexion.
Marquis of Lorne
@EJP c'est vrai ce n'est pas une erreur dans TLS mais l'échec de la connexion apparaît comme une erreur dans le code Java.
Brig
1
@Brig Mais pas comme une alerte, c'est ce que dit cette réponse et sur quoi porte la question.
Marquis of Lorne
15

Je ne pense pas que cela résout le problème du premier interrogateur, mais pour les googleurs qui viennent ici pour obtenir des réponses:


Sur la mise à jour 51, java 1.8 interdisait [1] les chiffrements RC4 par défaut, comme nous pouvons le voir sur la page Notes de publication:

Correction de bogue: interdire les suites de chiffrement RC4

RC4 est désormais considéré comme un chiffrement compromis.

Les suites de chiffrement RC4 ont été supprimées de la liste des suites de chiffrement activées par défaut du client et du serveur dans l'implémentation Oracle JSSE. Ces suites de chiffrement peuvent toujours être activées par des méthodes SSLEngine.setEnabledCipherSuites()et SSLSocket.setEnabledCipherSuites(). Voir JDK-8077109 (non public).

Si votre serveur a une forte préférence pour ce chiffrement (ou n'utilise que ce chiffrement), cela peut déclencher un handshake_failuresur java.

Vous pouvez tester la connexion au serveur en activant les chiffrements RC4 (d'abord, essayez sans enabledargument pour voir si le déclencheur a handshake_failure, puis définissez 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
la source
10

J'ai cette erreur pendant que j'essayais d'utiliser JDK 1.7. Lorsque j'ai mis à niveau mon JDK vers jdk1.8.0_66, tout a commencé à fonctionner correctement.

La solution la plus simple à ce problème pourrait donc être: mettez à niveau votre JDK et cela pourrait commencer à bien fonctionner.

Maxim Votyakov
la source
4
Agréable. La solution la plus simple consiste à mettre à niveau JDK? : D Savez-vous à quel point cela peut être compliqué en fonction de l'environnement dans lequel cela se fait? Supposons qu'Amazon exécute JDK 7 et qu'il doive maintenant passer à JDK 8 soudainement ... Bien!
Arturas M
1
Une simple mise à jour de version mineure a résolu ce problème pour moi. De JDK 11.0.1 à 11.0.6
Clint
5

Dans mon cas, le certificat est importé, l'erreur persiste, résolu cela en ajoutant System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3");avant de se connecter

molly gu
la source
A travaillé pour moi en java 1.8. Merci :)
Supun Amarasinghe
3

En supposant que vous utilisez les protocoles SSL / TLS appropriés, que vous avez correctement configuré votre keyStoreet que vous avez trustStoreconfirmé qu'il n'y a aucun problème avec les certificats eux-mêmes, vous devrez peut-être renforcer vos algorithmes de sécurité .

Comme mentionné dans la réponse de Vineet , l'une des raisons possibles pour lesquelles vous recevez cette erreur est due à l'utilisation de suites de chiffrement incompatibles. En mettant à jour mes local_policyet US_export_policyjars dans le securitydossier de mon JDK avec ceux fournis dans l' extension de cryptographie Java (JCE) , j'ai pu terminer la négociation avec succès.

heez
la source
2

Je rencontre le même problème aujourd'hui avec le client OkHttp pour OBTENIR une URL basée sur https. Cela était dû à la version du protocole Https et à l'incompatibilité de la méthode de chiffrement entre le côté serveur et le côté client .

1) Vérifiez la version du protocole https et la méthode de chiffrement de votre site Web.

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

Vous obtiendrez de nombreuses informations détaillées, les informations clés sont répertoriées comme suit:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
2) configurez votre client http, par exemple, dans le cas du client 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();
    }
}

Cela obtiendra ce que nous voulons.

Armstrongya
la source
2

J'ai trouvé un serveur HTTPS qui a échoué de cette manière si mon processus client Java était configuré avec

-Djsse.enableSNIExtension=false

La connexion a échoué avec une handshake_failurefois que le ServerHellos'est terminé avec succès mais avant le démarrage du flux de données.

Il n'y avait pas de message d'erreur clair identifiant le problème, l'erreur ressemblait simplement à

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

J'ai isolé le problème en essayant avec et sans l' -Djsse.enableSNIExtension=falseoption " "

Riches
la source
J'obtiens la même erreur lors de la connexion au bac à sable GDAX, des solutions pour cela?
Nitin Vavdiya
1

Le mien était une TLSerreur incompatible avec la version.

Auparavant, TLSv1je l'ai changé, TLSV1.2cela a résolu mon problème.

Ali786
la source
1

J'utilise le client http com.google.api. Lorsque je communique avec un site d'entreprise interne, j'ai ce problème lorsque j'ai utilisé par erreur https au lieu de 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
la source
Non, tu ne peux pas. Le serveur ne peut pas envoyer d'alerte TLS s'il ne parle pas TLS.
Marquis of Lorne
J'ai mis à jour mon commentaire pour afficher la sortie de mon programme. C'est réel. J'apprécierais que vous supprimiez le vote négatif.
thebiggestlebowski
C'est réel, mais ce n'est pas causé par la communication de TLS à un serveur de texte brut. Un serveur en clair ne parle pas TLS, par définition, et vous ne pouvez donc pas recevoir d'alerte TLS de sa part, par définition. Vous ne savez pas qui a voté contre votre réponse.
Marquis of Lorne
J'ai supposé que vous aviez voté - mes excuses si ce n'est pas le cas. Mon message d'erreur correspond exactement au titre de cette question. C'est un chemin / cas de test valide pour obtenir ce message d'erreur et j'ai une solution qui pourrait aider les autres. Respectueusement, je ne pense pas que ce soit important si cela est causé par une réponse d'erreur du serveur TLS ou non. Quelqu'un atterrira ici de google et ma réponse pourrait aider s'il a fait la même erreur.
thebiggestlebowski
Je n'ai rien dit à propos de votre message d'erreur. Je commente votre affirmation incorrecte selon laquelle cela est dû à `` l'utilisation par erreur de HTTPS au lieu de HTTP ''. Ce n'est pas, et cela ne peut pas être, pour des raisons que j'ai énoncées et auxquelles vous n'avez aucunement répondu. L'utilisation de HTTP le fera certainement disparaître, évidemment, car il n'y a pas d'alertes TLS en texte clair, mais ne résout pas le problème sous-jacent.
Marquis of Lorne
1

J'ai eu un problème similaire; la mise à niveau vers Apache HTTPClient 4.5.3 l'a corrigé.

Hazel Troost
la source
1

Ugg! Cela s'est avéré être simplement un problème de version Java pour moi. J'ai eu l'erreur de poignée de main en utilisant JRE 1.6 et tout fonctionnait parfaitement avec JRE 1.8.0_144.

John
la source
0

Avis de non-responsabilité: je ne sais pas si la réponse sera utile pour de nombreuses personnes, partageant simplement parce que cela pourrait.

J'obtenais cette erreur en utilisant Parasoft SOATest pour envoyer une requête XML (SOAP).

Le problème était que j'avais sélectionné le mauvais alias dans la liste déroulante après avoir ajouté le certificat et l'avoir authentifié.

user3251882
la source
0

Dans mon cas, le site Web peut simplement utiliser TLSv1.2. et j'utilise apache httpclient 4.5.6, j'utilise ce code et j'installe jce pour résoudre ce problème (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
la source
0

Pour dépanner du point de vue du développeur (élément 1) et de l'administrateur système (éléments 2 et 3):

  1. Activez le débogage de la négociation SSL sur Java via -Djavax.net.debug=ssl:handshake:verbose.
  2. Installez ssldump sur le serveur via sudo apt install ssldumpou compilez à partir des sources en suivant ce lien si vous observez Unknown valuedans le chiffrement lorsque vous exécutez l'étape ci-dessous.
  3. Au serveur, sudo ssldump -k <your-private-key> -i <your-network-interface>
  4. Vérifiez le journal sur la raison réelle de l'échec.

Exemple de non-fonctionnement de la négociation du journal 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

Exemple de négociation réussie du journal 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

Exemple de journal Java qui ne fonctionne pas

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
la source
0

Dans mon cas, j'ai eu un problème avec la version 1.1. Je reproduisais facilement le problème avec curl. Le serveur ne prenait pas en charge les versions inférieures à TLS1.2.

Ce problème de prise de contact a été reçu:

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

Avec la version 1.2, cela fonctionnait bien:

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

Le serveur exécutait un Weblogic et l'ajout de cet argument dans setEnvDomain.sh l'a fait fonctionner avec TLSv1.1:

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1
ravenskater
la source
0

Ce problème se produit à cause de la version java. J'utilisais 1.8.0.231 JDK et j'obtenais cette erreur. J'ai dégradé ma version java de 1.8.0.231 à 1.8.0.171, maintenant cela fonctionne bien.

hariom gupta
la source