J'ai un client Java essayant d'accéder à un serveur avec un certificat auto-signé.
Lorsque j'essaie de publier sur le serveur, j'obtiens l'erreur suivante:
impossible de trouver un chemin de certification valide vers la cible demandée
Après avoir fait quelques recherches sur la question, j'ai ensuite fait ce qui suit.
- J'ai enregistré le nom de domaine de mes serveurs dans un
root.cer
fichier. - Dans le JRE de mon serveur Glassfish, j'ai exécuté ceci:
keytool -import -alias example -keystore cacerts -file root.cer
- Pour vérifier que le certificat a bien été ajouté à mon cacert, j'ai fait ceci:
keytool -list -v -keystore cacerts
je peux voir que le certificat est présent. - J'ai ensuite redémarré Glassfish et retiré le «poste».
Je reçois toujours la même erreur.
J'ai l'impression que c'est parce que mon Glassfish ne lit pas réellement le fichier cacert que j'ai modifié mais peut-être un autre.
Avez-vous eu ce problème et pouvez-vous me pousser dans la bonne direction?
Réponses:
Malheureusement - cela pourrait être beaucoup de choses - et beaucoup de serveurs d'applications et d'autres «wrappers» java sont enclins à jouer avec les propriétés et leur «propre» prise sur les trousseaux et quoi d'autre. Il peut donc s'agir de quelque chose de totalement différent.
À court de fermes - j'essaierais:
pour voir si ça aide. Au lieu de «tout», vous pouvez également le définir sur «ssl», gestionnaire de clés et gestionnaire de confiance - ce qui peut vous aider dans votre cas. Le définir sur «aide» affichera quelque chose comme ci-dessous sur la plupart des plateformes.
Quoi qu'il en soit - assurez-vous de bien comprendre la différence entre le magasin de clés (dans lequel vous avez la clé privée et le certificat avec lequel vous prouvez votre propre identité) et le magasin de confiance (qui détermine à qui vous faites confiance) - et le fait que votre propre identité a une «chaîne» de confiance à la racine - qui est distincte de toute chaîne à une racine dont vous avez besoin pour comprendre «à qui» vous faites confiance.
Source: # Voir http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug
la source
Voici la solution, suivez le lien ci-dessous étape par étape:
http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/
FICHIER JAVA: absent du blog
la source
public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0];}
Vous devez configurer les propriétés système JSSE, en particulier pointer vers le magasin de certificats client.
Via la ligne de commande:
ou via du code Java:
Pour plus d'informations, reportez-vous aux détails sur le site RedHat .
la source
(republication de mon autre réponse )
Utilisez l' utilitaire cli keytool de distribution de logiciels java pour l' importation (et la confiance! ) les certificats nécessaires
Échantillon:
Du cli change dir en jre \ bin
Vérifier le fichier de clés (fichier trouvé dans le répertoire jre \ bin)
keytool -list -keystore .. \ lib \ security \ cacerts Le
mot de passe est changé
Téléchargez et enregistrez tous les certificats en chaîne à partir du serveur requis.
Ajoutez des certificats (avant de supprimer l'attribut "lecture seule" du fichier ".. \ lib \ security \ cacerts"), exécutez: keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore .. \ lib \ security \ cacerts -file "r: \ root.crt "
accidentellement, j'ai trouvé une astuce aussi simple. D'autres solutions nécessitent l'utilisation de InstallCert.Java et JDK
source: http://www.java-samples.com/showtutorial.php?tutorialid=210
la source
J'ai eu le même problème avec sbt .
Il a essayé de récupérer les dépendances de repo1.maven.org sur ssl
mais a déclaré qu'il "était incapable de trouver un chemin de certification valide vers l'URL cible demandée".
J'ai donc suivi ce post et je n'ai toujours pas vérifié la connexion.
J'ai donc lu à ce sujet et j'ai constaté que le certificat racine ne suffisait pas, comme l'a suggéré la publication, donc -
la chose qui a fonctionné pour moi était l'importation des certificats CA intermédiaires dans le magasin de clés .
J'ai en fait ajouté tous les certificats de la chaîne et cela a fonctionné comme un charme.
la source
Solution lors de la migration de JDK 8 vers JDK 10
certs
JDK 10
JDK 8
Étapes à suivre
jlink
comme/opt/jdk/bin/jlink \ --module-path /opt/jdk/jmods...
Alors, voici les différents chemins et la séquence des commandes ...
la source
Je travaille sur un didacticiel pour les services Web REST sur www.udemy.com (REST Java Web Services). L'exemple du didacticiel disait que pour avoir SSL, nous devons avoir un dossier appelé "trust_store" dans mon projet "client" d'éclipse qui devrait contenir un fichier "magasin de clés" (nous avions un projet "client" pour appeler le service et projet "service" qui contenait le service Web REST - 2 projets dans le même espace de travail éclipse, l'un le client, l'autre le service). Pour simplifier les choses, ils ont dit de copier "keystore.jks" à partir du serveur d'application glassfish (glassfish \ domain \ domain1 \ config \ keystore.jks) que nous utilisons et de le placer dans ce dossier "trust_store" dans lequel ils m'ont fait créer le projet client. Cela semble logique: les certificats auto-signés sur le serveur » s key_store correspondrait aux certificats du client trust_store. Maintenant, ce faisant, je recevais l'erreur que le message d'origine mentionne. J'ai googlé ceci et lu que l'erreur est due au fichier "keystore.jks" sur le client ne contenant pas de certificat approuvé / signé, que le certificat qu'il trouve est auto-signé.
Pour que les choses soient claires, permettez-moi de dire que si je comprends bien, le fichier "keystore.jks" contient des certificats auto-signés et le fichier "cacerts.jks" contient des certificats CA (signés par le CA). Le "keystore.jks" est le "keystore" et le "cacerts.jks" est le "trust store". Comme "Bruno", un commentateur, l'a dit plus haut, "keystore.jks" est local et "cacerts.jks" est destiné aux clients distants.
Donc, je me suis dit, hé, glassfish a aussi le fichier "cacerts.jks", qui est le fichier trust_store de glassfish. cacerts.jsk est censé contenir des certificats CA. Et apparemment, j'ai besoin que mon dossier trust_store contienne un fichier de stockage de clés contenant au moins un certificat CA. J'ai donc essayé de placer le fichier "cacerts.jks" dans le dossier "trust_store" que j'avais créé, sur mon projet client, et de modifier les propriétés de la machine virtuelle pour pointer sur "cacerts.jks" au lieu de "keystore.jks". Cela s'est débarrassé de l'erreur. Je suppose que tout ce dont il avait besoin était d'un certificat CA pour fonctionner.
Cela peut ne pas être idéal pour la production, ni même pour le développement au-delà du simple fait de faire fonctionner quelque chose. Par exemple, vous pourriez probablement utiliser la commande "keytool" pour ajouter des certificats CA au fichier "keystore.jks" dans le client. Mais de toute façon, j'espère que cela réduit au moins les scénarios possibles qui pourraient se produire ici pour provoquer l'erreur.
AUSSI: mon approche semblait utile pour le client (certificat serveur ajouté au client trust_store), il semble que les commentaires ci-dessus pour résoudre le message d'origine soient utiles pour le serveur (certificat client ajouté au serveur trust_store). À votre santé.
Configuration du projet Eclipse:
--- cacerts.jks --- keystore.jks
Extrait du fichier MyClientProject.java:
la source
Mon problème était qu'un courtier de sécurité d'accès au cloud, NetSkope, a été installé sur mon ordinateur portable professionnel via une mise à jour logicielle. Cela modifiait la chaîne de certificats et je ne pouvais toujours pas me connecter au serveur via mon client java après avoir importé la chaîne entière dans mon magasin de clés cacerts. J'ai désactivé NetSkope et j'ai réussi à me connecter.
la source
Dans mon cas, je faisais face au problème parce que dans mon processus tomcat, un magasin de clés spécifique a été donné en utilisant
Alors que j'importais le certificat dans le cacert de JRE / lib / security et que les changements ne se reflétaient pas. Ensuite, j'ai fait la commande ci-dessous où /tmp/cert1.test contient le certificat du serveur cible
Nous pouvons vérifier si l'importation du certificat a réussi
et voyez si votre serveur de taget est trouvé contre l'alias rapidssl-myserver
la source
Vérifiez si le fichier
$JAVA_HOME/lib/security/cacerts
existe! Dans mon cas, ce n'était pas un fichier mais un lien vers/etc/ssl/certs/java/cacerts
et c'était également un lien vers lui-même (QUOI ???) donc à cause de cela JVM ne peut pas trouver le fichier.Solution: copiez le vrai fichier cacerts ( vous pouvez le faire à partir d'un autre JDK ) dans le
/etc/ssl/certs/java/
répertoire et cela résoudra votre problème :)la source
rm -f /opt/jdk-minimal/jre/lib/security/cacerts ; ln -s /etc/ssl/certs/java/cacerts /opt/jdk-minimal/jre/lib/security/cacerts
Disons si vous utilisez des variables de chemin de classe comme $ {JAVA_HOME} dans pom.xml.
Sur les objectifs, ajoutez les variables classpath. c'est-à-dire .., -DANT_HOME, -DJAVA_HOME
la source