11 votes

Pourquoi j'obtiens un échec du handshake (Java SSL)

Je me connecte à un service web via HTTPS. J'ai fait tout ce que je pensais être nécessaire pour que cela fonctionne, mais au final, j'obtiens un échec de la poignée de main.

J'ai découvert qu'en tant que nouvel utilisateur, je ne peux pas poster plus de 2 liens à cause de la "protection anti-spam" - merci beaucoup à stackoverflow... de toute façon, voici un lien vers un post pastebin avec tous les liens en toutes lettres... donc quand j'écris "lien#1" ici, c'est une référence à ces liens : http://pastebin.com/y4zGNRC7

  • J'ai vérifié le même comportement en utilisant HttpClient (GET sur l'URL du service) et en appelant le service web via un proxy CXF.
  • Je configure à la fois le keystore et le truststore - j'ai essayé à la fois la méthode "dans le code" ( lien#1 ) et la configuration des propriétés du système - c'est-à-dire System.setProperty("javax.net.ssl.keyStore", "mykeystore.jks") ;
  • Le débogage SSL est activé ( javax.net.debug=all )
  • Le débogage SSL dévoile le contenu du keystore et du truststore (c'est-à-dire qu'on dirait que java "les connaît") - lien#2
  • il semble qu'il y ait une communication client-serveur, mais ensuite il se plante pour une raison quelconque lien#3
  • J'ai réussi à me connecter au serveur en utilisant les certificats du client et de l'autorité de certification dans un navigateur (Chrome) et en utilisant openssl s_client.
  • wireshark montre moins de conversation client-serveur à partir de java (lien 4) que, par exemple, à partir de Chrome (lien 5).

Une autre chose étrange est que je semble obtenir le même comportement lorsque je définis le keystore et lorsque je ne le fais pas (la seule différence est que lorsque je le fais, le contenu du keystore est affiché dans la console, mais c'est tout).

J'ai essayé de googler le problème et j'ai vu de nombreux messages similaires ici sur stackoverflow, mais rien n'a aidé. J'ai essayé de changer la version du protocole ("TLSv1", "SSLv3", même l'étrange v2 Hello). Toute aide serait appréciée - peut-être y a-t-il une chose fondamentale que j'aurais négligée... Je commence à désespérer... Merci

PS : j'utilise java 1.6 update 30 sur Fedora Core 15 (64bit).

5voto

Jakub Points 103

Le problème est que, bien que le keystore et le truststore aient été définis, java a décidé de ne pas envoyer le certificat du client au serveur. La raison en est que le serveur a demandé un certificat signé par l'autorité RootCA, mais le certificat du client est signé par une autorité SubCA (qui est émise par la RootCA).

À l'origine, le keystore ne contenait que le certificat du client et le truststore le certificat du SubCA. J'ai ensuite essayé d'ajouter le certificat SubCA au keystore également, mais java l'a simplement ignoré.

Cela résout donc le mystère de l'échec du hanshake, mais pas mon problème.

J'ai créé une question séparée pour cela...soupir :-( Pourquoi Java n'envoie-t-il pas le certificat du client pendant la prise de contact SSL ?

4voto

Michael Points 982

Je pense que le magasin de confiance ne contenant pas l'AC est le problème le plus probable. Vous pouvez utiliser l'outil Java keytool pour importer le certificat pour le site dans le cacerts en faisant quelque chose comme :

keytool -keystore pathtocacerts -import -trustcacerts -v -alias aliasName -file root.crt

Le mot de passe par défaut du keystore cacerts est changeit . Le site cacerts se trouve généralement sous jre/lib/security répertoire.

2voto

GregS Points 16158

Vous ne fournissez pas assez d'informations, mais je suppose que votre client truststore n'est pas correctement configuré. La base de confiance contient les certificats de confiance utilisés pour signer d'autres certificats, et doit inclure le(s) certificat(s) racine(s) pour les chaînes de certificats du serveur et du client. Le keystore du client contient le certificat SSL du client et sa clé privée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X