java.security.InvalidAlgorithmParameterException: le paramètre trustAnchors doit être non vide sous Linux ou la raison pour laquelle le fichier de clés certifiées est vide

Question

Lorsque vous recherchez Google pour cette exception: Java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty, plusieurs résultats apparaissent. Cependant, il n'y a pas de solution définitive, seulement des suppositions.

Le problème se pose (du moins dans mon cas) lorsque j'essaie d'utiliser une connexion ouverte via SSL. Cela fonctionne bien sur ma machine Windows, mais lorsque je le déploie sur la machine Linux (avec jre de Sun installé), il échoue avec l'exception ci-dessus.

Le problème est que le fichier de clés certifiées par défaut de JRE est vide pour une raison quelconque (taille de 32 octets seulement, alors qu'il est de 80 Ko sur Windows).

Quand j'ai copié mon fichier jre/lib/security/cacerts de Windows vers Linux, cela a bien fonctionné.

La question qui se pose est la suivante: pourquoi le jux linux dispose-t-il d’un trust store vide?

Notez que cela se produit sur une instance Amazon EC2, avec l'AMI Linux, ce qui pourrait être dû à certaines règles d'Amazon (je pense que Java était pré-installé, mais je ne suis pas sûr).

bestsss · Accepted Answer

Le Sun JDK standard pour Linux a un cacerts absolument correct et couvre tous les fichiers du répertoire spécifié. Le problème est l'installation que vous utilisez.

Andrew · Answer

J'ai évité cette erreur (Java 1.6.0 sur OSX 10.5.8) en plaçant un certificat factice dans le magasin de clés, tel que

keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit

La question devrait sûrement être "Pourquoi Java ne peut-il pas gérer un trustStore vide?"

Manuel Darveau · Answer

Pas la réponse à la question initiale mais en essayant de résoudre un problème similaire, j’ai trouvé que la mise à jour de Maverics pour Mac OS X avait gâché l’installation de Java (le cacert en fait). Supprimez Sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk et réinstallez du http://www.Oracle.com/technetwork/Java/javase/downloads/index.html

The Camster · Answer

Je peux générer cette erreur en définissant la propriété système trustStore dans un fichier jks manquant. Par exemple

 System.setProperty("javax.net.ssl.keyStore", "C:/keystoreFile.jks"); System.setProperty("javax.net.ssl.keyStorePassword", "mypassword"); System.setProperty("javax.net.ssl.trustStore", "C:/missing-keystore.jks"); System.setProperty("javax.net.ssl.trustStorePassword", "mypassword");

Ce code ne génère pas d'exception FileNotFound pour une raison quelconque, mais exactement l'exception InvalidAlgorithmParameter indiquée ci-dessus.

Une sorte de réponse idiote, mais je peux me reproduire.

superodde · Answer

Ma solution sous Windows consistait à exécuter la fenêtre de la console en tant qu'administrateur ou à modifier la variable d'environnement MAVEN_OPTS afin qu'elle utilise un chemin codé en dur vers trust.jks (par exemple, 'C:\Users\oddros') au lieu de '% USERPROFILE%'. Mon MAVEN_OPTS ressemble maintenant à ceci:

-Djavax.net.ssl.trustStore=C:\Users\oddros	rust.jks -Djavax.net.ssl.trustStorePassword=changeit

Daniele Dellafiore · Answer

Avait le même problème sur Ubuntu 14.10 avec Java-8-Oracle installé.

Installation du package ca-certificates-Java résolu:

Sudo apt-get install ca-certificates-Java

Ryan Shillington · Answer

Mon fichier cacerts était totalement vide. J'ai résolu ce problème en copiant le fichier cacerts à partir de ma machine Windows (utilisant Oracle Java 7) et en l'envoyant sur ma machine Linux (OpenJDK).

cd %Java_HOME%/jre/lib/security/ scp cacerts mylinuxmachin:/tmp

puis sur la machine linux

cp /tmp/cacerts /etc/ssl/certs/Java/cacerts

Cela a très bien fonctionné jusqu'à présent.

Paulo Henrique Lellis Gonalves · Answer

Assurez-vous que vous avez des cacerts valides dans le JRE/security, sinon vous ne contournerez pas l'erreur trustAnchors vide invalide.

Dans mon installation Amazon EC2 Opensuse12, le problème était que le fichier désigné par les cacerts dans le répertoire de sécurité JRE n'était pas valide:

$ Java -version Java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) $ ls -l /var/lib/ca-certificates/ -rw-r--r-- 1 root 363 Feb 28 14:17 ca-bundle.pem $ ls -l /usr/lib64/jvm/jre/lib/security/ lrwxrwxrwx 1 root 37 Mar 21 00:16 cacerts -> /var/lib/ca-certificates/Java-cacerts -rw-r--r-- 1 root 2254 Jan 18 16:50 Java.policy -rw-r--r-- 1 root 15374 Jan 18 16:50 Java.security -rw-r--r-- 1 root 88 Jan 18 17:34 nss.cfg

J'ai donc résolu l'installation d'un ancien certificat Opensuse 11 valide. (Désolé pour ça!!)

$ ll total 616 -rw-r--r-- 1 root 220065 Jan 31 15:48 ca-bundle.pem -rw-r--r-- 1 root 363 Feb 28 14:17 ca-bundle.pem.old -rw-r--r-- 1 root 161555 Jan 31 15:48 Java-cacerts

J'ai compris que vous pourriez utiliser l'outil de clé pour en générer un nouveau ( http://mail.openjdk.Java.net/pipermail/distro-pkg-dev/2010-avril/008961.html ). J'aurai probablement à cela bientôt.

cordialement lellis

Attila Szegedi · Answer

Si cela vous arrive avec une installation OpenJDK sur Mac OS X (par opposition à Linux) et que vous avez le programme officiel Mac OS X Java (c'est-à-dire le dernier Java 6) installé via Mise à jour de logiciels, procédez comme suit:

cd $OPENJDK_HOME/Contents/Home/jre/lib/security ln -s /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries

où $OPENJDK_HOME est le répertoire racine de votre installation OpenJDK, généralement OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk. Ceci est identique à la façon dont les installations Java officielles sur Mac OS X acquièrent ces fichiers - ils les connectent simplement par un lien symbolique depuis ces bundles système. Fonctionne pour Lion, pas certain pour les versions antérieures du système d'exploitation.

Pijush · Answer

Cela est dû au fait que les privilèges d'accès varient d'un système d'exploitation à l'autre. La hiérarchie d'accès Windows est différente d'Unix. Cependant, cela pourrait être surmonté en suivant ces étapes simples:

Augmenter l'accessibilité avec AccessController.doPrivileged(Java.security.PrivilegedAction subclass)
Définissez votre propre sous-classe Java.security.Provider en tant que propriété de sécurité . Security.insertProviderAt (new, 2);
Configurez votre Algorythm avec Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

Fuzzy Analysis · Answer

Je reçois la même erreur sur mon ordinateur Windows 7 lorsque les autorisations sur mon fichier cacerts dans mon dossier C:\Program Files\Java\jdk1.7.0_51\jre\lib\security ne sont pas définies correctement.

Pour résoudre le problème, j'autorise les utilisateurs SERVICE et INTERACTIVE à disposer de toutes les autorisations de modification sur cacerts sauf "modification des autorisations" et "prise en charge" (à partir des paramètres avancés, dans les propriétés de sécurité). Je suppose que le fait d'autoriser ces services à la fois à lire et à écrire des attributs étendus peut avoir quelque chose à voir avec l'erreur qui s'en va.

user2322889 · Answer

Avoir le même problème. Résolu en installant le paquet ca-certificate à partir de Mozilla:

$ zypper in ca-certificates-mozilla The following NEW package is going to be installed: ca-certificates-mozilla 1 new package to install. Retrieving package ca-certificates-mozilla-1.85-8.8.1.noarch (1/1), 143.7 KiB (239.1 KiB unpacked) Retrieving: ca-certificates-mozilla-1.85-8.8.1.noarch.rpm.....................[done] Installing: ca-certificates-mozilla-1.85-8.8.1 ...............................[done] Additional rpm output: Updating certificates in /etc/ssl/certs... 144 added, 0 removed. creating /var/lib/ca-certificates/ca-bundle.pem ... creating /var/lib/ca-certificates/Java-cacerts ... 144 added, 0 removed. $ ll /var/lib/ca-certificates/ total 392 drwxr-xr-x 2 root root 4096 Apr 26 07:25 ./ drwxr-xr-x 30 root root 4096 Apr 25 15:00 ../ -rw-r--r-- 1 root root 220196 Apr 26 07:25 ca-bundle.pem -rw-r--r-- 1 root root 161555 Apr 26 07:25 Java-cacerts

P.S.

$ cat /etc/SuSE-release openSUSE 12.2 (x86_64) VERSION = 12.2 CODENAME = Mantis $ Java -version Java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)