Erreur SSL "Homologue non authentifié" avec HttpClient 4.1
Je construis un moniteur d'application simple pour interroger l'une de nos URL d'API et nous envoyer un courrier électronique s'il ne peut pas obtenir un code d'état HTTP 200 de la réponse (cela indiquerait que notre API est en panne pour une raison quelconque).
J'utilise HttpClient 4.1 (ceci est important car son API diffère de grandement de 3.x).
Notre API est sécurisée avec SSL, en entrant toutefois:
dans un navigateur Web vous redirige vers
Sans causer d'erreurs.
Lorsque HttpClient tente de frapper cette URL (http://example.com/our-api), il échoue avec une exception javax.net.ssl.SSLPeerUnverifiedException avec un message indiquant:
peer non authentifié
Je constate que cela se produit souvent pour d’autres personnes, comme le montre this post (qui fournit également des moyens de contourner ce problème - une solution que je vais essayer d’appliquer ce soir en fait).
Ce que cet autre article (et d'autres similaires) ne font pas, c'est expliquer pourquoi cela se produit en premier lieu! Donc, plutôt que de demander "comment puis-je résoudre ce problème?" Je pensais que je demanderais "pourquoi cela se produit-il?" Avant de poursuivre avec l'une des solutions proposées, j'aimerais savoir quel est le problème que je tente de résoudre ;-)
Si le certificat du serveur est auto-signé, cela fonctionne comme prévu et vous devrez importer le certificat du serveur dans votre magasin de clés.
En supposant que le certificat de serveur soit signé par une autorité de certification connue, cela est dû au fait que l'ensemble de certificats d'autorité de certification disponible pour un navigateur moderne est beaucoup plus volumineux que l'ensemble limité fourni avec JDK/JRE.
La solution EasySSL fournie dans l’un des messages que vous avez mentionnés masque simplement l’erreur, et vous ne saurez pas si le serveur dispose d’un certificat valide.
Vous devez importer l'autorité de certification racine appropriée dans votre magasin de clés pour valider le certificat. Il y a une raison pour laquelle vous ne pouvez pas contourner cela avec le code SSL standard, c'est pour vous empêcher d'écrire des programmes qui se comportent comme s'ils étaient sécurisés mais ne le sont pas.
Ceci est jeté quand
... l'homologue n'a pas pu s'identifier (par exemple; certificat no , la suite de chiffrement particulière utilisée ne prend pas en charge l'authentification ou aucune authentification d'homologue n'a été établie lors du protocole SSL ) cette exception Est lancé.
Probablement la cause de cette exception (où est le stacktrace) vous montrera pourquoi cette exception est levée. Le fichier de clés par défaut fourni avec Java ne contient probablement pas (et ne fait pas confiance) le certificat racine du TTP utilisé.
La solution consiste à récupérer le certificat racine (par exemple, à partir de la connexion SSL de votre navigateur), à l'importer dans le fichier cacerts et à le lui faire confiance à l'aide de keytool fourni par le JDK Java. Sinon, vous devrez affecter un autre magasin de données de confiance par programme.
keytool -import -v -alias cacerts -keystore cacerts.jks -storepass changeit -file C:\cacerts.cer
Je ne suis pas un développeur Java mais utilisais une application Java pour tester une API RESTful. Afin que je puisse corriger l'erreur, je devais installer les certificats intermédiaires dans le serveur Web afin de faire disparaître l'erreur. J'utilisais lighttpd, le certificat d'origine était installé sur un serveur IIS. J'espère que ça aide. C'étaient les certificats qui me manquaient sur le serveur.
- CA.crt
- UTNAddTrustServer_CA.crt
- AddTrustExternalCARoot.crt