Erreur - le paramètre trustAnchors doit être non vide


492

J'essaie de configurer mon e-mail sur Jenkins / Hudson et je reçois constamment l'erreur:

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
    non-empty

J'ai vu une bonne quantité d'informations en ligne sur l'erreur, mais je n'en ai pas réussi à travailler. J'utilise le JDK de Sun sur Fedora Linux (pas OpenJDK).

Voici quelques choses que j'ai essayées. J'ai essayé de suivre les conseils de ce post , mais la copie des cacerts de Windows vers ma boîte Fedora hébergeant Jenkins n'a pas fonctionné. J'ai essayé de suivre ce guide en essayant de configurer Gmail comme mon serveur SMTP, mais cela n'a pas fonctionné non plus. J'ai également essayé de télécharger et de déplacer manuellement ces fichiers cacert et de les déplacer vers mon dossier Java en utilisant une variation des commandes de ce guide .

Je suis ouvert à toute suggestion car je suis actuellement bloqué en ce moment. Je l'ai fait fonctionner à partir d'un serveur Windows Hudson, mais je me bats sur Linux.

Réponses:


513

Ce message bizarre signifie que le magasin de confiance que vous avez spécifié était:

  • vide,
  • introuvable, ou
  • n'a pas pu être ouvert (en raison des autorisations d'accès par exemple).

Voir également la réponse de @ AdamPlumb ci-dessous .

Pour déboguer ce problème (j'ai écrit à ce sujet ici ) et comprendre quel truststore est utilisé, vous pouvez ajouter la propriété javax.net.debug = all, puis filtrer les journaux sur truststore. Vous pouvez également jouer avec la propriété javax.net.ssl.trustStore pour spécifier un magasin de clés de confiance spécifique. Par exemple :


    java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore

1
Merci EJP, j'ai vu votre message ici, mais je ne savais pas comment vérifier que le magasin de confiance était là. J'ai également fait apparaître mon fichier server.xml mais je ne savais pas comment vérifier que le fichier de clés certifiées était en place. Dois-je simplement vérifier le pref keystoreFile = "conf / .keystore" (keystoreFile n'était pas présent dans ce fichier)?
David Gill

2
La réponse était avec la façon dont je l'importais. Il me semblait avoir raté une étape cruciale. Voir [Erreur Java InvalidAlgorithmParameterException] [1] [1]: jyotirbhandari.blogspot.com/2011/09/…
David Gill

2
Confirmé que cette réponse est correcte. J'obtenais l'erreur sous Tomcat. J'avais mon magasin de confiance ${CATALINA_HOME}\confmais je n'étais CATALINA_HOMEpas prêt, donc Tomcat cherchait \confle magasin de confiance.
SingleShot

4
@BubblewareTechnology Non, l'erreur était dans le nom de fichier, pas dans la façon dont vous avez importé le certificat dans le fichier. Votre blog n'est pas correct. Vous ne devriez pas non plus recommander de modifier le fichier JRE $ / cacerts. Cela changera la prochaine mise à niveau de Java. Vous avez besoin d'un processus qui le copie, ajoute votre propre certificat à la copie et utilise la copie comme magasin de clés de confiance. Répétez chaque mise à niveau Java. Et vous n'avez pas du tout besoin de parler à Java de son propre magasin de clés de confiance, mais seulement du vôtre, s'il est différent.
Marquis de Lorne

3
J'ajouterai une touche: même lorsque le fichier de clés certifiées existe, est accessible, est au bon format, s'il est COMPLÈTEMENT VIDE, c'est l'erreur que vous pouvez obtenir avec diverses bibliothèques (y compris Apache HttpClient).
Alan Franzoni

265

Dans Ubuntu 18.04 , cette erreur a une cause différente (JEP 229, passer du jksformat par défaut du magasin de pkcs12clés au format, et la génération de fichiers Debian cacerts en utilisant la valeur par défaut pour les nouveaux fichiers) et solution :

# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
#  java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.

# 0. First make yourself root with 'sudo bash'.

# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
#    Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts

# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-java.postinst configure

État (2018-08-07) , le bogue a été corrigé dans Ubuntu Bionic LTS 18.04.1 et Ubuntu Cosmic 18.10.


Unt Ubuntu 1770553: [SRU] backport ca-certificats-java de cosmic (20180413ubuntu1)

🗹 Ubuntu 1769013: veuillez fusionner ca-certificats-java 20180413 (principal) de Debian unstable (principal)

🗹 Ubuntu 1739631: Une nouvelle installation avec JDK 9 ne peut pas utiliser le fichier de clés de cacerts PKCS12 généré

🗹 Docker -Library 145: l'image 9-jdk a des problèmes SSL

🗹 Debian 894979: ca-certificats-java: ne fonctionne pas avec OpenJDK 9, les applications échouent avec InvalidAlgorithmParameterException: le paramètre trustAnchors doit être non vide

🗹 JDK-8044445: JEP 229: création de magasins de clés PKCS12 par défaut

🖺 JEP 229: créer des magasins de clés PKCS12 par défaut


Si le problème persiste après cette solution de contournement, vous pouvez vous assurer que vous exécutez réellement la distribution Java que vous venez de corriger.

$ which java
/usr/bin/java

Vous pouvez définir les alternatives Java sur «auto» avec:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Vous pouvez vérifier la version Java que vous exécutez:

$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

Il existe également des solutions de rechange, mais celles-ci ont leurs propres effets secondaires qui nécessiteront une maintenance future supplémentaire, sans aucun avantage.

La solution de contournement suivante consiste à ajouter la ligne

javax.net.ssl.trustStorePassword=changeit

aux fichiers

/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties

selon ce qui existe.

La troisième solution de contournement la moins problématique consiste à modifier la valeur de

keystore.type=pkcs12

à

keystore.type=jks

dans les fichiers

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

celui qui existe, puis supprimez le cacertsfichier et régénérez-le de la manière décrite dans la dernière ligne du script de contournement en haut de la publication.


50
Utilisateurs d'Ubuntu 18, lisez ceci! cela sauvera de nombreuses heures de votre vie! Je vous remercie!
vak

5
Cette réponse m'a aidé à corriger la même erreur avec maven sur Ubuntu 18.04. J'ai dû changer le propriétaire du fichier / etc / ssl / certs / java / cacerts de root à moi-même pour pouvoir y écrire. Ensuite, je l'ai réactivé.
Yuri Gor

77
J'ai exécuté sudo rm / etc / ssl / certs / java / cacerts puis sudo update-ca-certificats -f et cela a résolu mon problème dans kubuntu 18.04.
jsn

2
@jsn, merci pour les solutions, fonctionne aussi sur linux mint 19 qui est basé sur ubuntu 18.04
Samrat

2
La solution de @ jsn a également fonctionné pour Debian Stretch + openjdk8
HRJ

105

Cela a résolu le problème pour moi sur Ubuntu:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

(trouvé ici: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

ca-certificates-java n'est pas une dépendance dans Oracle JDK / JRE, cela doit donc être explicitement installé.


2
Merci, cela a résolu le problème pour moi lorsque je l'ai rencontré sur Ubuntu 15.04.
Macil

A travaillé sur Raspbian sur Raspberry Pi
Defozo

1
Ran dans ce problème avec Debian jesse backports stables avec OpenJDK8 et cela a résolu le problème. J'utilisais cela lors de la création d'images Docker. :)
Tuxdude

9
Malheureusement, ne fonctionne pas sur Ubuntu MATE 18.04. Je vais essayer de réinstaller Java.
Pranav A.

1
@codefx - J'ai fait ce que vous suggérez et cela ne fonctionne pas - sur Ubuntu 18.x avec Java 10 (par défaut).
mzedeler

69

Sur Ubuntu 18.04, la cause première est un conflit entre openjdk-11-jdk (qui est par défaut) et d'autres packages en fonction. Il a déjà été corrigé dans Debian et sera bientôt inclus dans Ubuntu. Pendant ce temps, la solution la plus simple consiste à rétrograder votre java à la version 8. Les autres solutions employées ca-certificates-javasont beaucoup plus compliquées.

Supprimez d'abord les packages en conflit:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Vérifiez si vous avez supprimé tous les packages associés avec succès:

sudo update-alternatives --config java

Le système vous demandera qu'aucun Java n'est disponible pour la configuration , sinon cette solution de contournement échoue .

Réinstallez ensuite les packages requis:

sudo apt-get install openjdk-8-jdk

Cette description est factuellement incorrecte et ne résout le problème que dans le même sens que la réinstallation de Windows peut résoudre un problème. Il n'est pas nécessaire de supprimer tous les packages Java. Si vous souhaitez procéder de cette façon, il vous suffit d'installer le openjdk-8-jdkpackage, de supprimer le /etc/ssl/certs/java/cacertsfichier et d'exécuter sudo update-ca-certificates -fce qui est le moyen détourné de passer d'un pkcs12fichier cacerts formaté à un fichier jksformaté, comme décrit ailleurs dans ce fil.
Mikael Gueck

1
@MikaelGueck Bien que la logique semble être de votre côté, je suis ici pour vous assurer que j'ai déjà fait exactement ce qui est décrit dans votre commentaire et dans la plupart des autres réponses votées, et en 18.04, c'est la seule réponse qui a fonctionné . Je pense que votre downvote devrait se transformer en un upvote, ou du moins disparaître, car il n'est pas mérité.
Andrea Ligios

@AndreaLigios, vous pouvez lire vous-même les scripts, ils sont assez courts. Ils ont un ensemble codé en dur de chemins JAVA_HOME de 8 à 10, ils les essaient un par un, ils appellent le générateur de fichiers Debian CA que vous pouvez également lire, qui utilise le format de fichier existant, parce que le code du gestionnaire de fichier de clés JDK, qui vous pouvez lire, a un mode de secours de compatibilité. Si votre ordinateur exécute ce logiciel simple différemment, vous pourriez avoir d'autres problèmes avec lui. Avez-vous modifié vos alternatives java et appelé une autre machine virtuelle Java, car la suppression aurait pu réinitialiser les alternatives?
Mikael Gueck

1
@MikaelGueck oui, dans l'un des essais précédents, j'ai modifié mes alternatives java, donc c'était probablement ça. Je suis le premier qui aime fouiller dans le code source et trouver comment ça marche, mais ce n'était pas mon objectif aujourd'hui, c'était juste l'un des 5-6 différents obstacles inattendus que j'avais sur le chemin de mon objectif réel. Cette réponse m'a permis de résoudre le problème en moins de 2 minutes! Combien de temps aurais-je dû consacrer à la recherche de scripts et à la recherche d'une meilleure solution? Et pour quoi, pour économiser quelques mégaoctets? C'est drastique, mais fonctionne (et quel que soit le problème), donc un grand merci à OP pour ceux qui sont occupés comme l'enfer
Andrea Ligios

1
Je cherchais une solution depuis 2 jours, et votre réponse a résolu mon problème, merci. Je viens de passer à Kubuntu 18.04, cela a fonctionné.
guepardomar

55

EJP a essentiellement répondu à la question (et je me rends compte que la réponse est acceptée), mais je viens de traiter ce problème de bord et je voulais immortaliser ma solution.

J'ai eu l' InvalidAlgorithmParameterExceptionerreur sur un serveur Jira hébergé que j'avais précédemment configuré pour un accès SSL uniquement. Le problème était que j'avais configuré mon magasin de clés au format PKCS # 12, mais mon magasin de confiance était au format JKS.

Dans mon cas, j'avais édité mon server.xmlfichier pour spécifier le keystoreType à PKCS, mais je n'ai pas spécifié le truststoreType, donc il est par défaut quel que soit le keystoreType. Spécifier explicitement le truststoreType comme JKS l'a résolu pour moi.


Eh bien, je vous aide à immortaliser la solution à votre problème de bord. c'est là que ça devient intéressant.
n611x007

2
C'était exactement mon problème. J'utilisais Spring Boot 1.4.2.RELEASE et j'avais un magasin de clés matériel et logiciel. J'ai spécifié le fournisseur et le type du magasin de clés, mais pas le magasin de clés de confiance. Par conséquent, le fournisseur et le type incorrects ont été utilisés par le magasin de clés de confiance. La spécification de ceux (SUN et JKS) a résolu le problème.
Kenco

12
comment avez-vous fait cela exactement? (fenêtres ici)
tatsu

2
Rencontrez cela avec mon grandle Android aujourd'hui, je comprends presque ce que vous dites mais vous ne dites pas comment le résoudre. Réponse non utile
Lothar

52

J'ai rencontré cette solution à partir d'un article de blog Fixing the trustAnchors problem when running OpenJDK 7 on OS X :

Correction du problème trustAnchors lors de l'exécution d'OpenJDK 7 sur OS X. Si vous exécutez OpenJDK 7 sur OS X et avez vu cette exception:

Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
    parameter must be non-empty

Il existe une solution simple. Il suffit de lier dans le même fichier cacerts que le JDK 1.6 d'Apple:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

Vous devez le faire pour chaque version d'OpenJDK que vous avez installée. Modifiez simplement -v 1.7la version que vous souhaitez corriger. Exécutez /usr/libexec/java_home -Vpour voir tous les JRE et JDK que vous avez installés.

Peut-être que les gars d'OpenJDK pourraient l'ajouter à leurs scripts d'installation.


1
Ma commande "ln" (sur OSX 10.6.8) n'a pas d'option "h"; que faut-il faire?
Andrew Swan

1
Ah, j'avais deux commandes "ln", une dans / usr / bin (par défaut) et une dans / bin; ce dernier avait une option "h" et travaillait.
Andrew Swan

J'ai corrigé mon installation cassée 1.6 reliant aux cacerts de l'installation du système 1.8 avec cette technique ln. Merci!
A21z

1
Pour les futurs lecteurs: il semble que vous avez aussi besoin des 3 autres fichiers qui sont dans le securitydossier ( blacklisted.certs, local_policy.jaret US_export_policy.jar) pour Java pour être heureux.
awksp

@Peter Kriens, pourquoi être lié au cacertssous- jrerépertoire?
BAE

45

Dans Ubuntu 12.10 (Quantal Quetzal) ou version ultérieure, les certificats sont conservés dans le paquet ca-certificats-java . L'utilisation -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsles récupérera quel que soit le JDK que vous utilisez.


54
J'ai trouvé que je devais exécuter update-ca-certificates -fmanuellement, pour remplir le fichier cacerts
Portablejim

4
@Portablejim Merci. Votre commentaire a résolu le premier problème que j'ai rencontré lors de la construction d'Apache Spark sur Ubuntu 15.04beta.
Paul

1
Merci @Portablejim, votre commentaire a fonctionné pour moi sur Ubuntu 15.04.
David Berg

Merci. Ceci est résolu mon problème avec PhpStrom + JDK patché. J'ai écrit cette clé dans le fichier "phpstorm64.vmoptions".
Vijit

Ne fonctionne pas pour moi dans Ubuntu 18.04 et JDK est 1.8.0_62
Devendra Singraul

34

J'ai rencontré ce problème exact sous OS X, en utilisant JDK 1.7, après la mise à niveau vers OS X v10.9 (Mavericks). Le correctif qui a fonctionné pour moi était de simplement réinstaller la version Apple de Java, disponible sur http://support.apple.com/kb/DL1572 .


J'ai rencontré cela avec Java 6 utilisé par Grails sur OSX. J'ai également installé Java 7 d'Oracle et également mis à niveau vers Mavericks. La réinstallation de Java 6 à partir du site Web d'Apple a également résolu le problème pour moi.
pm_labs

Ran dans cela lors de l'installation open jdk 6 sur une boîte cloud ubuntu. Ravi de voir un visage familier, BTW
Ben Hutchison

30

L'Iran

sudo update-ca-certificates -f

pour créer un fichier de certificat, puis:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

J'étais de retour dans les affaires, merci les gars. C'est dommage qu'il ne soit pas inclus dans l'installation, mais j'y suis finalement arrivé.


Quand je cours, sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**je reçoissudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found
Magick

Suffit sudo update-ca-certificates -fsuffit sur Debian jessie avec openjdk-8-jre-headlessde jessie-backports, tant qu'il ca-certificates-javaest installé. Je pense que l'ordre d'installation est important (JRE après ca-certificates-javapeut provoquer cela, car ce dernier n'a pas de déclencheurs pour Java 8 rétroporté).
mirabilos

2
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure sans étoiles **
Yu Jiaao

update-ca-certificates -fest la chose qui l'a réparé. Je n'avais pas besoin de la 2e commande
Mark Jeronimus

17

L'erreur indique que le système ne peut pas trouver le fichier de clés certifiées dans le chemin d'accès fourni avec le paramètre javax.net.ssl.trustStore.

Sous Windows, j'ai copié le cacertsfichier jre/lib/securitydans le répertoire d'installation d'Eclipse (au même endroit que le eclipse.inifichier) et ajouté les paramètres suivants dans eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

J'ai eu quelques problèmes avec le chemin vers les cacerts (la variable d'environnement% java_home% est en quelque sorte écrasée), j'ai donc utilisé cette solution triviale.

L'idée est de fournir un chemin d'accès valide au fichier truststore - idéalement, ce serait d'utiliser un chemin relatif. Vous pouvez également utiliser un chemin absolu.

Pour vous assurer que le type de magasin est JKS, vous devez exécuter la commande suivante:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

2
C'est la seule réponse qui a réellement fonctionné. Merci @razvanone
Akshar Patel

1
J'ai réussi à frapper un petit "gotcha": les trois lignes du fichier eclipse.ini doivent se trouver sur trois lignes distinctes. Au départ, je les ai tous mis sur une même ligne et Eclipse n'a pas compris cela.
SiKing

16

La suppression du package ca-certificats-java et sa réinstallation ont fonctionné pour moi ( Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Merci, jdstrand: Commentaire 1 pour le bogue 983302, Re: ca-certificats-java ne parvient pas à installer les cacerts Java sur Oneiric Ocelot .


11

J'ai eu beaucoup de problèmes de sécurité après la mise à niveau vers OS X v10.9 (Mavericks):

  • Problème SSL avec Amazon AWS
  • Homologue non authentifié avec Maven et Eclipse
  • trustAnchors le paramètre doit être non vide

J'ai appliqué cette mise à jour Java et elle a résolu tous mes problèmes: http://support.apple.com/kb/DL1572?viewlocale=en_US


5
Pouah. Java 6 a dépassé de plusieurs années la fin du support public et est sûrement criblé de failles de sécurité. Apple le rend disponible au téléchargement afin que les anciens logiciels qui ne peuvent pas être exécutés avec Java 7/8 puissent continuer à s'exécuter, mais il ne doit pas être utilisé pour établir des connexions SSL aux services sur Internet public, tels que 1. AWS, 2. Maven Central, 3. rien d'autre.
Zac Thompson

10

Je m'attendais à des choses comme ça, étant que j'utilise une JVM alternative dans mon Talend Open Studio (le support n'existe pour le moment que jusqu'à JDK 1.7). J'utilise 8 pour des raisons de sécurité ... de toute façon

  • Mettez à jour votre magasin de certificats:

    sudo update-ca-certificates -f

puis

  • ajouter une nouvelle valeur dans vos paramètres d'initialisation

    sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)
    
    Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Pour moi, la deuxième entrée a fonctionné. Je pense que, selon la version de Talend Open Studio / TEnt + JVM, il a un nom de paramètre différent, mais il recherche le même fichier de clés.


4
D'où avez-vous obtenu la propriété javax.net.ssl.trustAnchors? Il n'est pas mentionné dans la documentation JSSE.
Marquis de Lorne

10

Pour moi, cela a été causé par le manque d'un trustCertEntry dans le truststore.

Pour tester, utilisez:

keytool -list -keystore keystore.jks

Ça me donne:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Même si mon PrivateKeyEntry contient une autorité de certification, elle devait être importée séparément :

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

Il importe le certificat, puis la relance keytool -list -keystore keystore.jksdonne maintenant:

Your keystore contains 2 entries

cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1):
<fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1):
<fingerprint>

Maintenant, il a un TrustCertEntry, et Tomcat démarrera avec succès.


NB consultez le tutoriel baeldung avec un Makefile utile comme raccourci pour créer un magasin de clés et un magasin de confiance (projet spring-security-x509) baeldung.com/x-509-authentication-in-spring-security
hello_earth

9

Certaines versions des fournisseurs OpenJDK ont provoqué cela en ayant un cacertsfichier vide distribué avec le binaire. Le bug est expliqué ici: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Vous pouvez copier dans adoptOpenJdk8\jre\lib\security\cacertsle fichier à partir d'une ancienne installation comme c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

La version du buggy AdoptOpenJDK est https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip


Je pense que c'était aussi le cas pour moi. Dans AdoptOpenJDK 202, ce bogue est présent, et dans 222 cela fonctionne. Mettez donc à jour votre jdk si possible.
Marty

6

Si vous rencontrez cela sur Ubuntu avec JDK9 et Maven, vous pouvez ajouter cette option JVM - vérifiez d'abord si le chemin existe:

-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Si le fichier est manquant, essayez d'installer le ca-certificats-java comme quelqu'un l'a noté:

sudo apt install ca-certificates-java

Si vous utilisez Docker, vous pouvez également essayer l'image "maven: 3-jdk-9-slim" au lieu de "maven: 3-jdk-9"
Konstantin Pavlov

Merci, cela a fonctionné pour moi pour openjdk-8-jdk dans Ubuntu 18.04
Aftab Naveed

4

J'ai eu ce message d'erreur sur Java 9.0.1 sous Linux. Cela était dû à un bogue connu du JDK, où le fichier cacerts est vide dans le paquet binaire .tar.gz (téléchargé depuis http://jdk.java.net/9/ ).

Voir le paragraphe "Problèmes connus" des notes de mise à jour de JDK 9.0.1 , indiquant «TLS ne fonctionne pas par défaut sur OpenJDK 9».

Sur Debian / Ubuntu (et probablement d'autres dérivés), une solution de contournement simple consiste à remplacer le fichier cacerts par celui du paquet "ca-certificate-java":

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Sur Red Hat Linux / CentOS, vous pouvez faire de même à partir du package "ca-certificats":

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

4

J'ai eu ce problème lors de la tentative d'utilisation de Maven 3, après la mise à niveau d' Ubuntu 16.04 LTS (Xenial Xerus) vers Ubuntu 18.04 LTS (Bionic Beaver).

La vérification de / usr / lib / jvm / java-8-oracle / jre / lib / security a montré que mon fichier cacerts était un lien symbolique pointant vers /etc/ssl/certs/java/cacerts .

J'ai également eu un dossier suspect cacerts.original.

Je renomme cacerts.originalà cacerts, et résolu le problème.


Le cacerts.originalfichier était au jksformat et a été généré avec Java 8 d'Ubuntu 16.04, qui utilisait ce format par défaut. Le cacertsfichier était au pkcs12format, généré par Java 10 d'Ubuntu 18.04, qui utilise ce format par défaut. Comme expliqué ailleurs dans ce fil, le nouveau format nécessite que vous passiez le mot de passe à l'exécutable. Mais tant que vous générez un nouveau jks cacertsfichier vide ou copiez un ancien, le processus de génération de cacerts suivant videra le fichier existant et le remplira avec les certificats CA du système de fichiers.
Mikael Gueck

3

J'ai également rencontré cela sur OS X après la mise à jour d'OS X v10.9 (Mavericks), lorsque l'ancien Java 6 était utilisé et que j'essayais d'accéder à une URL HTTPS. Le correctif était l'inverse de Peter Kriens; J'avais besoin de copier le cacertsde l'espace 1.7 vers l'emplacement lié par la version 1.6:

(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/java_home -v 1.7)/jre/lib/security/cacerts \
    /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security

1
La commande ici essaie de copier un répertoire dans un fichier; cela n'a absolument aucun sens.
praseodym

Je suis d'accord avec l'évaluation de l'utilisation d'une solution inverse. J'ai trouvé que jdk1.6 avait un lien logiciel /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home/lib/security/cacerts -> /System/Library/Java/Support/CoreDeploy.bundle / Sommaire / Accueil / lib / security / cacerts. J'ai donc enregistré le lien logiciel cassé, puis copié les cacerts de l'installation jdk1.7.
James A Wilson

REMARQUE: lorsque vous avez terminé, vous devriez pouvoir récupérer le fichier cacerts que vous avez copié pour valider les autorisations.
Gray

En outre, fixé le cp pour aller dans la bonne direction et ajouté le umask pour mkdir et cp.
Gray

3

Dans mon cas, le fichier JKS utilisé dans l'application client était corrompu. J'en ai créé un nouveau et y ai importé les certificats SSL du serveur de destination. Ensuite, j'ai utilisé le nouveau fichier JKS dans l'application cliente comme magasin de confiance, comme:

System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);

Source: Java SSL et magasin de clés de certificats

J'utilise l'outil (KeyStore Explorer) pour créer le nouveau JKS. Vous pouvez le télécharger à partir de ce lien, KeyStore Explorer .


keystore-explorer a fait le travail pour moi. Il vous suffit de créer un fichier de clés par défaut et d'examiner et d'enregistrer le fichier de certificat pour le site / l'hôte.
Shantha Kumara

3

Vous pouvez également rencontrer cette erreur après la mise à niveau vers Spring Boot 1.4.1 (ou plus récent) car il apporte Tomcat 8.5.5 dans le cadre de ses dépendances.

Le problème est dû à la façon dont Tomcat traite le magasin de confiance. Si vous avez spécifié l'emplacement de votre magasin de clés de confiance comme votre magasin de clés dans la configuration Spring Boot, vous obtiendrez probablement le trustAnchors parameter must be non-emptymessage lors du démarrage de l'application.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Supprimez simplement la server.ssl.trust-storeconfiguration sauf si vous savez que vous en avez besoin, auquel cas consultez les liens ci-dessous.

Les problèmes suivants contiennent plus de détails sur le problème:


3

J'ai rencontré ce problème avec le sdkmanager du SDK Android. Pour moi, cette solution a fonctionné:

  1. Aller à /usr/lib/jvm/java-8-oracle/jre/lib/security/
  2. Remplacez cacertparcacert.original

Le cacertfichier était minuscule (22B). J'ai installé oracle-java8-installerdepuis ppa:webupd8team/java(selon ce manuel: https://docs.nativescript.org/start/ns-setup-linux ).


2

Pour mémoire, aucune des réponses ici n'a fonctionné pour moi. Ma génération Gradle a commencé à échouer mystérieusement avec cette erreur, impossible de récupérer HEAD depuis Maven central pour un fichier POM particulier .

Il s'est avéré que JAVA_HOME était réglé sur ma propre version personnelle d'OpenJDK, que j'avais construite pour déboguer un problème javac. Le remettre sur le JDK installé sur mon système l'a corrigé.


... ce qui a empêché de trouver le magasin de confiance, selon les autres réponses.
Marquis de Lorne

1
Oui, mais savoir que le truststore ne peut pas être trouvé est totalement inutile si vous ne pouvez pas comprendre pourquoi il n'est pas trouvé. Il existe de nombreuses façons possibles de se tromper, et c'est frustrant lorsqu'aucune d'entre elles n'est la façon particulière dont elle échoue pour votre propre système.
user3562927

Ils se produisent tous comme la même erreur: le magasin de clés de confiance spécifié n'a pas pu être ouvert ou était vide. Il existe un million de façons dont cette situation pourrait se produire, et il n'y a pas assez d'espace sur SO pour les énumérer toutes.
Marquis de Lorne

1

Sur Red Hat Linux, j'ai résolu ce problème en important les certificats dans /etc/pki/java/cacerts.


1
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");

Vous devez ajouter les deux lignes ci-dessus à votre code. Il n'est pas en mesure de trouver le magasin de clés de confiance.


2
Si vous ne le faites pas, il utilisera le magasin de clés de confiance JRE, et il pourra certainement le trouver. L'erreur est causée par des valeurs incorrectes dans ces paramètres, et non par leur absence. Le fichier nommé dans votre code s'applique uniquement à votre installation, pas en général.
Marquis de Lorne

La bonne façon de définir ces propriétés consiste à les passer sur la ligne de commande: java -Djavax.net.ssl.trustStore=/tmp/cacerts ...ou si vous souhaitez les définir globalement pour tous les programmes exécutés avec un JDK, ajoutez la ligne au management.propertiesfichier du JDK .
Mikael Gueck

1

J'ai rencontré ce problème lors de l'exécution d'une suite particulière d'Android pour les tests sur Ubuntu 14.04 (Trusty Tahr). Deux choses ont fonctionné pour moi comme suggéré par shaheen:

sudo update-ca-certificates -f

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

1

Aucune des solutions que j'ai trouvées sur Internet n'a fonctionné, mais une version modifiée de la réponse de Peter Kriens semble faire l'affaire.

Trouvez d'abord votre dossier Java en exécutant /usr/libexec/java_home. Pour moi, c'était la 1.6.0.jdkversion. Allez ensuite dans son lib/securitysous-dossier (pour moi /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Supprimez ensuite le cacertsfichier s'il en existe déjà un et recherchez-en un sur le système avec sudo find / -name "cacerts". Il a trouvé plusieurs éléments pour moi, dans les versions de Xcode ou d'autres applications que j'avais installées, mais aussi sur /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacertslesquelles j'avais choisi.

Utilisez ce fichier et créez un lien symbolique vers celui-ci (dans le dossier Java d'avant) sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", et cela devrait fonctionner.

J'ai les deux - Java à partir du téléchargement d'Apple 2017-001 ( https://support.apple.com/kb/dl1572 - je suppose que c'est de là que proviennent les certificats appropriés) et celui d'Oracle installé sur Mac OS X v10.12 (Sierra) .


1

sur Ubuntu 14.04 avec openjdk 11 de ppa: openjdk-r / ppa cela a fonctionné pour moi:

dans java.security, remplacez le type de fichier de clés par

keystore.type=jks

puis:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

lorsque vous vérifiez si cela a fonctionné, assurez-vous que vous n'utilisez aucun démon avec l'ancien Java toujours en cours d'exécution (par exemple, l' --no-daemonoption pour gradle)

ce bogue décrit tout bien et vous aidera à comprendre ce qui se passe sur https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631


1

Sur Ubuntu 18.04, j'avais besoin d'utiliser OpenJDK 1.7 pour la maintenance d'un ancien projet. J'ai téléchargé le package binaire. Mais quand j'ai exécuté mon script dessus, j'ai eu la même erreur.

La solution a été de supprimer le cacertsfichier du JDK téléchargé dans le jre/lib/securitydossier puis de le créer en tant que lien symbolique vers le cacertsfichier système dans /etc/ssl/certs/java/:

sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts


1

Peu de chances que cela aide tout le monde, mais ... pour tous ceux qui exécutent Java 8 à partir d'une image Docker sur un Raspberry Pi (utilisant un processeur AMD), j'ai obtenu le fichier Dockerfile suivant à construire et à exécuter avec succès pour moi

FROM hypriot/rpi-java
USER root

WORKDIR /usr/build/

RUN /usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

EXPOSE 8080

ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar

ADD ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.