Java.sécurité.InvalidAlgorithmParameterException: le paramètre trustAnchors doit être non vide sous Linux, ou pourquoi le truststore par défaut est-il vide [dupliquer]

J'ai eu cette erreur dans Ubuntu. J'ai vu que /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts était un lien cassé vers /etc/ssl/certs/java / cacerts. Cela m'a conduit à ce bug: https://bugs.launchpad.net/ubuntu/ + source / ca-certificats-java/ + bug / 983302 Le README pour ca-certificates-java a finalement montré le correctif réel:

Exécuter

update-ca-certificates -f

Apt-get install ca-certificates-java n'a pas fonctionné pour moi. Il vient de le marquer comme installé manuellement.

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

Sûrement la question devrait être " Pourquoi java ne peut-il pas gérer un trustStore vide?"

Pas la réponse à la question d'origine mais en essayant de résoudre un problème similaire, j'ai trouvé que la mise à jour Mac OS X vers Maverics a foiré l'installation java (le cacert en fait). Supprimer sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk et réinstaller à partir de http://www.oracle.com/technetwork/java/javase/downloads/index.html

Je peux générer cette erreur en définissant la propriété système trustStore sur 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 répertoriée ci-dessus.

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

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

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

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

Résolu installation du paquet ca-certificates-java:

sudo apt-get install ca-certificates-java

Mon fichier cacerts était totalement vide. J'ai résolu ce problème en copiant le fichier cacerts sur ma machine Windows (qui utilise Oracle Java 7) et en le scpant sur ma boîte 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.

Si cela vous arrive avec une installation OpenJDK sur Mac OS X (par opposition à Linux), et que vous avez le Java officiel de Mac OS X (c'est-à-dire le dernier Java 6) installé via la mise à jour logicielle, vous pouvez simplement le faire:

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, typiquement 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 lient simplement symboliquement à partir de ces bundles système. Fonctionne pour Lion, pas sûr pour les versions antérieures de la OS.

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 pointé 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 valide Opensuse 11. (désolé à ce sujet!!)

$ 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 pouvez utiliser le keytool pour en générer un nouveau ( http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html ). Je devrai probablement le faire bientôt.

Cordialement lellis

Ont le même problème. Résolu en installant ca-certificate bundle 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)

Cela se produit parce que le privilège d'accès varie d'un SYSTÈME d'exploitation à l'AUTRE. La hiérarchie d'accès Windows est différente de celle d'Unix. Cependant, cela pourrait être surmonté en suivant ces étapes simples:

1. Augmenter l'accessibilité avec AccessController.doPrivileged(java.security.PrivilegedAction subclass)
2. Définissez votre propre sous-classe java.security.Provider comme propriété de sécurité. sécurité.insertProviderAt(nouvelle , 2);
3. Définissez votre algorithme avec Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

J'obtiens cette même erreur sur ma machine Windows 7 lorsque les autorisations sur mon fichier cacerts dans mon C:\Program Les fichiers \ Java \ jdk1.7. 0_51\jre\lib\security ne sont pas correctement définis.

Pour résoudre le problème, j'autorise le SERVICE et les utilisateurs INTERACTIFS à avoir toutes les autorisations de modification sur cacerts sauf "modifier les autorisations" et "prendre possession" (à partir des paramètres avancés, dans les propriétés de sécurité). Je suppose que permettre à ces services de lire et d'écrire des attributs étendus peut avoir quelque chose à voir avec l'erreur qui disparaît.