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 par défaut est vide

Question

Lorsque vous faites une recherche google pour cette exception: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty, plusieurs résultats apparaissent. Cependant il n'existe pas de solution définitive, seulement des suppositions.

Le problème se pose (dans mon cas au moins) lorsque j'essaie d'ouvrir une connexion SSL. Il fonctionne très bien sur ma machine windows, mais quand je la déployer sur la machine linux (avec du soleil jre installé), il échoue avec l'exception ci-dessus.

Le problème est que la valeur par défaut truststore de la JRE est vide pour une raison quelconque (taille de 32 octets, alors qu'elle est de 80 ko sur windows).

Lorsque j'ai copié mon jre/lib/security/cacerts le fichier à partir de windows à linux, il a bien fonctionné.

La question est pourquoi est - linux jre avoir un vide de trust store?

Notez que ce qui se passe sur une instance Amazon EC2, avec l'AMI linux, donc ça peut être dû à des amazon politiques (je pense que java a été pré-installé, mais je ne suis pas sûr)

Answer 1

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.

Answer 2

J'ai évité cette erreur (Java 1.6.0 sur OSX 10.5.8) en mettant 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?"

Answer 3

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-le à partir de http://www.oracle.com/technetwork/java/javase/downloads/index.html.

Answer 4

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 d'accès 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: \ Utilisateurs \ oddros \ trust.jks -Djavax.net.ssl.trustStorePassword = changeit

Answer 5

Si cela vous arrive avec un OpenJDK installer sur Mac OS X (contrairement à Linux), et vous avez le officiel Mac OS X Java (c'est à dire dernière version de Java 6) installé par le Logiciel de mise à Jour, il vous suffit de faire ceci:

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 OpenJDK installer, typiquement OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk. C'est identique à la façon officielle de Java s'installe sur Mac OS X de l'acquisition de ces fichiers - ils aussi juste lien symbolique de ceux du système de bundles. Fonctionne pour Lion, ne sais pas pour les versions antérieures de l'OS.