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

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.

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

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.

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é.

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

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.

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.

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.

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 .

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é.

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

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 .

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

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.

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.

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

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

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

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.

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

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 .

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:

• Le connecteur HTTPS Tomcat ne démarre pas avec 1.4.1 # 7069
• SSL-client-auth avec certificat auto-signé a cessé de fonctionner # 7406
• Mettre à niveau vers Tomcat 8.5.5 # 6703

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 ).

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é.

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

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.

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

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) .

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

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

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"]