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

Le JDK 25 le signale sous la forme « javax.net.ssl.SSLException: (internal_error) Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty », avec « java.lang.RuntimeException: Unexpected error: … » dans la chaîne des causes. Un chemin de magasin de confiance qui n’existe pas du tout donne plutôt « PKIX path building failed ».

Java (JSSE / PKIX) — the trust store the JVM loaded contains no trusted certificates

Ce que cela signifie

La JVM a chargé un magasin de confiance qui ne contient aucune entrée de certificat de confiance : le validateur PKIX n’a donc aucune ancre de confiance et refuse de démarrer. Cela se produit avant la vérification de tout certificat : le fichier existe et s’ouvre, mais il est vide du point de vue de la confiance TLS. Toutes les connexions HTTPS du processus échouent de la même manière.

Pourquoi cela se produit

• Un magasin de clés a été configuré comme magasin de confiance

  fréquente

  javax.net.ssl.trustStore pointe vers un fichier qui ne contient que des entrées de clé privée (la clé propre au client ou au serveur) et aucune entrée de certificat de confiance.

• Le cacerts du JDK est vide ou a été remplacé

  fréquente

  Certains paquets de distribution génèrent cacerts à partir du bundle de certificats du système lors de l’installation ; une étape de post-installation en échec, une image de conteneur minimale ou un lien symbolique cassé laisse un magasin vide.

• Un magasin créé pour un autre usage

  occasionnelle

  Un magasin tout juste créé (keytool -genkeypair puis -delete, ou un PKCS12 vide produit par un script) qui n’a jamais été rempli de certificats d’AC.

Comment corriger l’erreur

1. 1.

   Compter les entrées de confiance

   keytool -list affiche les entrées ; un magasin de confiance a besoin de lignes trustedCertEntry. Comparez avec le magasin par défaut du JDK.

   # How many trusted certificates does the store hold? (0 reproduces this error)
   keytool -list -keystore "$TRUSTSTORE" -storepass "$TRUSTSTORE_PASSWORD" | grep -c trustedCertEntry
   keytool -list -cacerts -storepass changeit | grep -c trustedCertEntry    # the JDK's default store

2. 2.

   Restaurer le magasin de confiance par défaut du JDK

   Sous Debian et Ubuntu, réinstaller ca-certificates-java régénère /etc/ssl/certs/java/cacerts ; sous Alpine, c’est le paquet java-cacerts qui le fournit.

   # Debian/Ubuntu OpenJDK packages build cacerts from the system CA bundle
   sudo apt-get install --reinstall ca-certificates-java
   sudo update-ca-certificates -f
   # Alpine
   apk add --no-cache java-cacerts

3. 3.

   Séparer magasin de clés et magasin de confiance

   Passez votre propre certificat et votre clé via javax.net.ssl.keyStore, et les certificats d’AC via javax.net.ssl.trustStore.

   # Key store (your key + certificate) and trust store (CAs you trust) are different files
   java -Djavax.net.ssl.keyStore=client.p12   -Djavax.net.ssl.keyStorePassword=changeit \
        -Djavax.net.ssl.trustStore=truststore.p12 -Djavax.net.ssl.trustStorePassword=changeit -jar app.jar

← Parcourir toute la base de données des erreurs de signature