Erreur des certificats SSL Debian: impossible de vérifier le certificat xxx / javax.net. ssl. SSLHandshakeException
J'ai un problème étrange (c'est un problème de configuration de serveur à 100%,) par exemple, je veux télécharger quelque chose depuis Dropbox:
Résolution dl.dropboxusercontent.com 2 23.23.160.146, 50.17.227.107, 54.221.248.69, ... Connexion à dl.dropboxusercontent.com/23.23.160.146/:443 connected connecté. ERREUR: impossible de vérifier dl.dropboxusercontent.com certificat, délivré par "/C=US/ST=CA / O=SonicWall Inc./ CN=SonicWall Firewall DPI-SSL":
Certificat auto-signé rencontré. De se connecter à dl.dropboxusercontent.com sans sécurité, utilisez ‘no no-check-certificate'.
Oui, je sais que je peux utiliser certificate non-check-certificate mais quand je veux utiliser la connexion SSL dans l'application Java, j'ai quelque chose comme ceci:
Javax.net.le protocole ssl.SSLHandshakeException: soleil.sécurité.validateurs.ValidatorException: échec de la construction du chemin PKIX: soleil.sécurité.Fournisseur.certpath.SunCertPathBuilderException: impossible de trouver le chemin de certification valide à demandé cible
Cette application fonctionne très bien dans d'autres serveurs ou dans les machines locales, des idées ce qui ne va pas ici?
2 answers
/ C = US / ST = CA / O=SonicWall Inc./ CN=SonicWall Firewall DPI-SSL
Votre trafic est visiblement intercepté par un pare-feu deep packet inspection qui agit comme un proxy MITM pour surveiller votre trafic.
Cela peut généralement être considéré comme un attaquant MITM "légitime". (Aussi légitime que cela puisse être, cela dépend d'un certain nombre d'aspects juridiques et éthiques.) Votre administrateur réseau local devrait être en mesure de vous en dire un peu plus à ce sujet. Si cela fait partie d'une société réseau, cette société surveille votre trafic, y compris le contenu de votre connexion HTTPS (il n'est donc plus sécurisé de bout en bout). Si le pare-feu fait son travail correctement, il devrait toujours sécuriser la connexion du pare-feu au serveur (Il est probablement difficile de savoir s'il vérifie correctement les certificats.)
En général, un tel pare-feu ou proxy agit comme sa propre Autorité de certification, forgeant efficacement chaque certificat tel que demandé.
La plupart des clients sur le le réseau d'entreprise ferait confiance aux certificats qu'il émet (comme celui auquel vous êtes confronté) car les administrateurs système installeraient également le certificat CA en tant que certificat de confiance sur chaque machine de ce réseau. Vous l'avez probablement les certificats racine de confiance du système d'exploitation.
Cependant, il est probable que les administrateurs réseau n'aient pas installé ce certificat d'autorité de certification dans votre installation JRE (qui utilise son propre ensemble d'ancres de confiance par défaut).
Essayez d'exporter ce certificat d'autorité de certification (voir le nom ci-dessus) à partir d'une machine de référence et importez-la dans le truststore que vous utilisez (soit le truststore par défaut de votre JRE: cacerts ou un nouveau truststore que vous créez et transmettez à votre application via les propriétés javax.net.trustStore).
Typiquement, vous pouvez utiliser quelque chose comme ceci (en supposant que vous avez exporté l'autorité de certification du pare-feu comme "firewallca.pem"):
keytool -import -file firewallca.pem -alias firewallca -keystore truststore.jks
Si le fichier truststore.jks n'existe pas, il sera créé. Sinon, vous pouvez prendre une copie du fichier cacerts dans le répertoire lib/security de votre JRE. Vous peut également le faire directement sur le fichier cacerts (en utilisant -keystore /path/to/truststore.jks, à condition que vous y ayez accès en écriture).
Si vous choisissez de ne pas le faire sur le truststore par défaut (ce fichier cacerts) mais utilisez un truststore local comme truststore.jks, vous pouvez l'utiliser en utilisant cette propriété système lors de l'exécution de votre application: -Djavax.net.trustStore=/path/to/truststore.jks
Pour d'autres façons de configurer votre truststore, vérifiez cette réponse.
Une autre façon de résoudre ce problème consiste à dire à Java d'utiliser le truststore de votre système d'exploitation. Je suppose que vous utilisez Windows ici. L'utilisation de ces propriétés système devrait fonctionner:
-Djavax.net.trustStore=NONE -Djavax.net.trustStoreType=WINDOWS-ROOT
(Essayez avec WINDOWS-MY au lieu de WINDOWS-ROOT si cela ne fonctionne pas.)
Le WINDOWS-MY/WINDOWS-ROOT est un peu bogué en ce sens qu'il manquera certains des certificats dans le Windows Store: il utilise le certificat "friendly name" (non unique) comme alias keystore (unique), donc un certificat avec un nom amical donné masquera les autres avec le même nom. (Cela réduit efficacement le nombre de CA certificats qui sont approuvés malheureusement.)
Puisque vous êtes dans un environnement où vraisemblablement tout le trafic passe par votre pare-feu DPI, vous n'aurez probablement qu'à utiliser un seul certificat CA au maximum. Tant qu'il ne partage pas son "nom convivial" dans la liste Windows avec un autre certificat, cela devrait aller.
Vous devez ajouter le certificat SSL du serveur dans le magasin de clés Java de votre client. Jetez un oeil à ce post SO:
ASTUCE: C'est parce que la JVM de votre client ne fait pas "confiance" au certificat SSL du serveur. Vous devez donc ajouter le certificat dans votre magasin de clés.