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

JDK 25 reports it as "javax.net.ssl.SSLException: (internal_error) Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty", with "java.lang.RuntimeException: Unexpected error: …" in the cause chain. A trust store path that does not exist at all gives "PKIX path building failed" instead.

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

What it means

The JVM loaded a trust store that contains no trusted certificate entries, so the PKIX validator has no trust anchors at all and refuses to start. It happens before any certificate is checked: the file exists and opens, but it is empty for TLS trust purposes. Every HTTPS connection of the process fails the same way.

Why it happens

• A key store was configured as the trust store

  common

  javax.net.ssl.trustStore points at a file that only holds private-key entries (the client's or server's own key) and no trusted certificate entries.

• The JDK's cacerts is empty or was replaced

  common

  Some distribution packages generate cacerts from the system bundle at install time; a failed post-install step, a minimal container image or a broken symlink leaves an empty store.

• A store created for another purpose

  occasional

  A freshly created store (keytool -genkeypair then -delete, or an empty PKCS12 from a script) that was never filled with CA certificates.

How to fix it

1. 1.

   Count the trusted entries

   keytool -list shows the entries; a trust store needs trustedCertEntry lines. Compare with the JDK's default store.

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

   Restore the JDK's default trust store

   On Debian and Ubuntu, reinstalling ca-certificates-java regenerates /etc/ssl/certs/java/cacerts; on Alpine the java-cacerts package provides it.

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

   Keep key store and trust store separate

   Pass your own certificate and key as javax.net.ssl.keyStore and the CA certificates as 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

← Browse the full signature error database