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

JDK 25 meldet den Fehler als „javax.net.ssl.SSLException: (internal_error) Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty“, mit „java.lang.RuntimeException: Unexpected error: …“ in der Kette der Ursachen. Ein Pfad zu einem Trust Store, der gar nicht existiert, führt stattdessen zu „PKIX path building failed“.

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

Was der Fehler bedeutet

Die JVM hat einen Trust Store geladen, der keine Einträge mit vertrauenswürdigen Zertifikaten enthält, daher hat der PKIX-Validator überhaupt keine Vertrauensanker und verweigert den Start. Das passiert, bevor irgendein Zertifikat geprüft wird: Die Datei existiert und lässt sich öffnen, ist aber für Vertrauensentscheidungen bei TLS leer. Jede HTTPS-Verbindung des Prozesses scheitert auf dieselbe Weise.

Warum der Fehler auftritt

• Ein Keystore wurde als Trust Store konfiguriert

  häufig

  javax.net.ssl.trustStore verweist auf eine Datei, die nur Einträge mit privaten Schlüsseln enthält (den eigenen Schlüssel des Clients oder Servers) und keine Einträge mit vertrauenswürdigen Zertifikaten.

• Die Datei cacerts des JDK ist leer oder wurde ersetzt

  häufig

  Manche Distributionspakete erzeugen cacerts bei der Installation aus dem System-Bundle; ein fehlgeschlagener Post-Install-Schritt, ein minimales Container-Image oder ein defekter Symlink hinterlässt einen leeren Store.

• Ein Store, der für einen anderen Zweck angelegt wurde

  gelegentlich

  Ein frisch angelegter Store (keytool -genkeypair und danach -delete oder eine leere PKCS12-Datei aus einem Skript), der nie mit CA-Zertifikaten befüllt wurde.

So behebst du den Fehler

1. 1.

   Vertrauenswürdige Einträge zählen

   keytool -list zeigt die Einträge; ein Trust Store braucht Zeilen mit trustedCertEntry. Vergleiche mit dem Standard-Store des 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.

   Mitgelieferten Trust Store des JDK wiederherstellen

   Unter Debian und Ubuntu erzeugt eine Neuinstallation von ca-certificates-java die Zertifikatsdatei /etc/ssl/certs/java/cacerts neu; unter Alpine stellt das Paket java-cacerts sie bereit.

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

   Keystore und Trust Store getrennt halten

   Übergib dein eigenes Zertifikat und deinen Schlüssel als javax.net.ssl.keyStore und die CA-Zertifikate als 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

← Gesamte Signaturfehler-Datenbank durchsuchen