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

JDK 25 lo notifica como «javax.net.ssl.SSLException: (internal_error) Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty», con «java.lang.RuntimeException: Unexpected error: …» en la cadena de causas. Una ruta de almacén de confianza que ni siquiera existe da, en cambio, «PKIX path building failed».

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

Qué significa

La JVM cargó un almacén de confianza que no contiene ninguna entrada de certificado de confianza, así que el validador PKIX no tiene ninguna ancla de confianza y se niega a arrancar. Ocurre antes de comprobar ningún certificado: el archivo existe y se abre, pero está vacío a efectos de confianza TLS. Todas las conexiones HTTPS del proceso fallan igual.

Por qué ocurre

• Se configuró un almacén de claves como almacén de confianza

  frecuente

  javax.net.ssl.trustStore apunta a un archivo que solo contiene entradas de clave privada (la clave propia del cliente o del servidor) y ninguna entrada de certificado de confianza.

• El cacerts del JDK está vacío o se sustituyó

  frecuente

  Algunos paquetes de distribución generan cacerts durante la instalación a partir del conjunto de certificados del sistema; un paso posterior a la instalación que falla, una imagen de contenedor mínima o un enlace simbólico roto dejan un almacén vacío.

• Un almacén creado para otro fin

  ocasional

  Un almacén recién creado (keytool -genkeypair y después -delete, o un PKCS12 vacío generado por un script) que nunca se llenó con certificados de CA.

Cómo solucionarlo

1. 1.

   Contar las entradas de confianza

   keytool -list muestra las entradas; un almacén de confianza necesita líneas trustedCertEntry. Compáralo con el almacén predeterminado del 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.

   Restaurar el almacén de confianza predeterminado del JDK

   En Debian y Ubuntu, reinstalar ca-certificates-java regenera /etc/ssl/certs/java/cacerts; en Alpine lo proporciona el paquete java-cacerts.

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

   Separar el almacén de claves y el almacén de confianza

   Pasa tu propio certificado y tu clave como javax.net.ssl.keyStore, y los certificados de CA como 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

← Explorar toda la base de datos de errores de firma