Error: el parámetro trustAnchors no debe estar vacío

Estoy tratando de configurar mi correo electrónico en Jenkins / Hudson, y constantemente recibo el error:

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

He visto una buena cantidad de información en línea sobre el error, pero no he conseguido que funcione. Estoy usando Sun's JDK en Fedora Linux (no OpenJDK).

Aquí hay algunas cosas que he probado. Intenté seguir los consejos de esta publicación , pero copiar los cacerts de Windows a mi caja Fedora que alojaba a Jenkins no funcionó. Intenté seguir esta guía mientras intento configurar Gmail como mi servidor SMTP, pero tampoco funcionó. También intenté descargar y mover esos archivos cacert manualmente y moverlos a mi carpeta Java usando una variación de los comandos de esta guía .

Estoy abierto a cualquier sugerencia ya que actualmente estoy atrapado en este momento. Lo hice funcionar desde un servidor de Windows Hudson, pero estoy teniendo problemas con Linux.

Este mensaje extraño significa que el almacén de confianza que especificó fue:

• vacío,
• no encontrado, o
• no se pudo abrir (debido a permisos de acceso, por ejemplo).

Vea también la respuesta de @ AdamPlumb a continuación .

Para depurar este problema (lo escribí aquí ) y comprender qué almacén de confianza se está utilizando, puede agregar la propiedad javax.net.debug = all y luego filtrar los registros sobre el almacén de confianza. También puede jugar con la propiedad javax.net.ssl.trustStore para especificar un almacén de confianza específico. Por ejemplo :

    java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore

En Ubuntu 18.04 , este error tiene una causa diferente (JEP 229, cambia del jksformato predeterminado del almacén de claves al pkcs12formato y la generación de archivos Cacerts de Debian usa el predeterminado para los archivos nuevos) y solución alternativa :

# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
#  java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.

# 0. First make yourself root with 'sudo bash'.

# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
#    Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts

# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-java.postinst configure

Estado (2018-08-07) , el error se ha corregido en Ubuntu Bionic LTS 18.04.1 y Ubuntu Cosmic 18.10.

🗹 Ubuntu 1770553: [SRU] backport ca-certificados-java de cosmic (20180413ubuntu1)

🗹 Ubuntu 1769013: Combine ca-certificados-java 20180413 (principal) de Debian inestable (principal)

🗹 Ubuntu 1739631: la instalación nueva con JDK 9 no puede usar el archivo de almacén de claves generado por PKCS12 generado

🗹 docker-library 145: la imagen 9-jdk tiene problemas de SSL

🗹 Debian 894979: ca-certificados-java: no funciona con OpenJDK 9, las aplicaciones fallan con InvalidAlgorithmParameterException: el parámetro trustAnchors no debe estar vacío

D JDK-8044445: JEP 229: Crear almacenes de claves PKCS12 de forma predeterminada

EP JEP 229: Crear almacenes de claves PKCS12 por defecto

Si el problema continúa después de esta solución alternativa, es posible que desee asegurarse de que realmente está ejecutando la distribución de Java que acaba de solucionar.

$ which java
/usr/bin/java

Puede configurar las alternativas de Java a 'auto' con:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Puede verificar la versión de Java que está ejecutando:

$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

También existen soluciones alternativas, pero tienen sus propios efectos secundarios que requerirán un mantenimiento adicional futuro, sin ningún beneficio.

La siguiente mejor solución es agregar la fila

javax.net.ssl.trustStorePassword=changeit

a los archivos

/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties

lo que exista

La tercera solución alternativa menos problemática es cambiar el valor de

keystore.type=pkcs12

a

keystore.type=jks

en los archivos

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

lo que exista, y luego elimine el cacertsarchivo y vuelva a generarlo de la manera descrita en la última fila del script de solución alternativa en la parte superior de la publicación.

Esto solucionó el problema para mí en Ubuntu:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

(encontrado aquí: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

ca-certificates-java no es una dependencia en Oracle JDK / JRE, por lo que debe instalarse explícitamente

En Ubuntu 18.04, la causa raíz es un conflicto entre openjdk-11-jdk (que es el valor predeterminado) y otros paquetes que dependen de él. Ya se ha solucionado en Debian y se incluirá en Ubuntu en breve. Mientras tanto, la solución más simple es degradar su Java a la versión 8. Otras soluciones empleadas ca-certificates-javason mucho más complicadas.

Primero elimine los paquetes en conflicto:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Compruebe si eliminó con éxito todos los paquetes relacionados:

sudo update-alternatives --config java

El sistema le indicará que no hay Java disponible para configurar , de lo contrario, esta solución falla .

Luego reinstale los paquetes requeridos:

sudo apt-get install openjdk-8-jdk

Básicamente, EJP respondió la pregunta (y me doy cuenta de que esta tiene una respuesta aceptada), pero acabo de lidiar con este problema de caso extremo y quería inmortalizar mi solución.

Tuve el InvalidAlgorithmParameterExceptionerror en un servidor Jira alojado que había configurado previamente para acceso solo SSL. El problema era que había configurado mi almacén de claves en el formato PKCS # 12, pero mi almacén de confianza estaba en el formato JKS.

En mi caso, había editado mi server.xmlarchivo para especificar el keytoreType a PKCS, pero no especifiqué el truststoreType, por lo que el valor predeterminado es cualquiera que sea el keystoreType. Especificando el truststoreType explícitamente como JKS lo resolvió para mí.

Me encontré con esta solución desde la publicación del blog Solucionando el problema trustAnchors al ejecutar OpenJDK 7 en OS X :

Solución del problema trustAnchors al ejecutar OpenJDK 7 en OS X. Si está ejecutando OpenJDK 7 en OS X y ha visto esta excepción:

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

Hay una solución simple. Simplemente enlace en el mismo archivo cacerts que utiliza JDK 1.6 de Apple:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

Debe hacer esto para cada versión de OpenJDK que haya instalado. Simplemente cambie -v 1.7a la versión que desea arreglar. Ejecute /usr/libexec/java_home -Vpara ver todos los JRE y JDK que ha instalado.

Quizás los chicos de OpenJDK podrían agregar esto a sus scripts de instalación.

En Ubuntu 12.10 (Quantal Quetzal) o posterior, los certificados se encuentran en el paquete ca-certificados-java . El uso -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertslos recogerá independientemente de qué JDK esté usando.

Me encontré con este problema exacto en OS X, usando JDK 1.7, después de actualizar a OS X v10.9 (Mavericks). La solución que funcionó para mí fue simplemente reinstalar la versión de Apple de Java, disponible en http://support.apple.com/kb/DL1572 .

Yo corri

sudo update-ca-certificates -f

para crear un archivo de certificado y luego:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Estaba de vuelta en el negocio, gracias chicos. Es una pena que no esté incluido en la instalación, pero al final llegué allí.

El error indica que el sistema no puede encontrar el almacén de confianza en la ruta provista con el parámetro javax.net.ssl.trustStore.

En Windows, copié el cacertsarchivo jre/lib/securityen el directorio de instalación de Eclipse (mismo lugar que el eclipse.iniarchivo) y agregué la siguiente configuración en eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

Tuve algunos problemas con la ruta a los cacerts (la variable de entorno% java_home% se sobrescribe de alguna manera), por lo que utilicé esta solución trivial.

La idea es proporcionar una ruta válida al archivo del almacén de confianza, idealmente sería usar uno relativo. También puede usar una ruta absoluta.

Para asegurarse de que el tipo de tienda es JKS, debe ejecutar el siguiente comando:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Eliminar el paquete ca-certificados-java e instalarlo nuevamente funcionó para mí ( Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Gracias, jdstrand: Comentario 1 para el error 983302, Re: ca-certificados-java no puede instalar los cacerts de Java en Oneiric Ocelot .

He tenido muchos problemas de seguridad después de actualizar a OS X v10.9 (Mavericks):

• Problema SSL con Amazon AWS
• Compañero no autenticado con Maven y Eclipse
• trustAnchors el parámetro no debe estar vacío

Apliqué esta actualización de Java y solucionó todos mis problemas: http://support.apple.com/kb/DL1572?viewlocale=en_US

Esperaba cosas como esta, ya que uso un JVM alternativo en mi Talend Open Studio (el soporte actualmente solo existe hasta JDK 1.7). Yo uso 8 por motivos de seguridad ... de todos modos

• Actualice su tienda de certificados:

  sudo update-ca-certificates -f

entonces

• agregue un nuevo valor en sus parámetros de inicialización

  sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)
  
  Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Para mí, la segunda entrada funcionó. Creo que, dependiendo de la versión de Talend Open Studio / TEnt + JVM, tiene un nombre de parámetro diferente, pero busca el mismo archivo de almacén de claves.

Para mí fue causado por la falta de un TrustedCertEntry en el almacén de confianza.

Para probar, use:

keytool -list -keystore keystore.jks

Me da:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Aunque mi PrivateKeyEntry contiene una CA, se debe importar por separado :

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

Importa el certificado y luego volver a ejecutarlo keytool -list -keystore keystore.jksahora proporciona:

Your keystore contains 2 entries

cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1):
<fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1):
<fingerprint>

Ahora tiene un TrustedCertEntry, y Tomcat comenzará con éxito.

Algunos lanzamientos de proveedores de OpenJDK causaron esto al tener un cacertsarchivo vacío distribuido con el binario. El error se explica aquí: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Puede copiar al adoptOpenJdk8\jre\lib\security\cacertsarchivo desde una instalación antigua como c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

La versión con errores de AdoptOpenJDK es https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Si experimenta esto en Ubuntu con JDK9 y Maven, puede agregar esta opción JVM: primero verifique si la ruta existe:

-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Si falta el archivo, intente instalar ca-certificados-java como alguien señaló:

sudo apt install ca-certificates-java

Recibí este mensaje de error en Java 9.0.1 en Linux. Fue debido a un error conocido del JDK, donde el archivo cacerts está vacío en el paquete binario .tar.gz (descargado de http://jdk.java.net/9/ ).

Consulte el párrafo "problemas conocidos" de las notas de la versión JDK 9.0.1 , que dice "TLS no funciona de manera predeterminada en OpenJDK 9".

En Debian / Ubuntu (y probablemente otras derivadas), una solución simple es reemplazar el archivo cacerts con el del paquete "ca-certificados-java":

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

En Red Hat Linux / CentOS, puede hacer lo mismo desde el paquete "ca-certificados":

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Tuve este problema al intentar usar Maven 3, después de actualizar de Ubuntu 16.04 LTS (Xenial Xerus) a Ubuntu 18.04 LTS (Bionic Beaver).

Comprobar / usr / lib / jvm / java-8-oracle / jre / lib / security mostró que mi archivo cacerts era un enlace simbólico que apuntaba a /etc/ssl/certs/java/cacerts .

También tenía un archivo sospechosamente nombrado cacerts.original.

Cambié el nombre cacerts.originala cacerts, y eso solucionó el problema.

También encontré esto en OS X después de actualizar OS X v10.9 (Mavericks), cuando se usaba el antiguo Java 6 e intentaba acceder a una URL HTTPS. La solución fue la inversa de Peter Kriens; Necesitaba copiar cacertsdesde el espacio 1.7 a la ubicación vinculada por la versión 1.6:

(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/java_home -v 1.7)/jre/lib/security/cacerts \
    /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security

En mi caso, el archivo JKS utilizado en la aplicación cliente estaba dañado. Creé uno nuevo e importé los certificados SSL del servidor de destino. Luego usé el nuevo archivo JKS en la aplicación cliente como un almacén de confianza, como:

System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);

Fuente: Java SSL y certificado de almacén de claves

Uso la herramienta (KeyStore Explorer) para crear el nuevo JKS. Puede descargarlo desde este enlace, KeyStore Explorer .

También puede encontrar este error después de actualizar a Spring Boot 1.4.1 (o más reciente) porque trae Tomcat 8.5.5 como parte de sus dependencias.

El problema se debe a la forma en que Tomcat trata con la tienda de confianza. Si ha especificado que la ubicación de su tienda de confianza es la misma que su almacén de claves en la configuración de Spring Boot, es probable que reciba el trustAnchors parameter must be non-emptymensaje al iniciar la aplicación.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Simplemente elimine la server.ssl.trust-storeconfiguración a menos que sepa que la necesita, en cuyo caso consulte los enlaces a continuación.

Los siguientes problemas contienen más detalles sobre el problema:

• El conector HTTPS Tomcat no se inicia con 1.4.1 # 7069
• SSL-client-auth con certificado autofirmado dejó de funcionar # 7406
• Actualice a Tomcat 8.5.5 # 6703

Encontré este problema con el SDK de Android SDKmanager. Para mí esta solución funcionó:

1. Ir /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. Reemplazar cacertconcacert.original

El cacertarchivo era pequeño (22B). He instalado oracle-java8-installerdesde ppa:webupd8team/java(de acuerdo con este manual: https://docs.nativescript.org/start/ns-setup-linux ).

Para el registro, ninguna de las respuestas aquí funcionó para mí. Mi compilación de Gradle comenzó a fallar misteriosamente con este error, incapaz de obtener HEAD desde Maven central para un archivo POM particular .

Resultó que tenía JAVA_HOME configurado en mi propia versión personal de OpenJDK, que había creado para depurar un problema de javac. Ajustándolo nuevamente al JDK instalado en mi sistema lo arregló.

En Red Hat Linux resolví este problema importando los certificados /etc/pki/java/cacerts.

System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");

Debe agregar las dos líneas anteriores a su código. No puede encontrar el almacén de confianza.

Enfrenté este problema mientras ejecutaba un conjunto particular de Android para probar en Ubuntu 14.04 (Trusty Tahr). Dos cosas funcionaron para mí como lo sugirió shaheen:

sudo update-ca-certificates -f

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Ninguna de las soluciones que encontré en Internet funcionó, pero una versión modificada de la respuesta de Peter Kriens parece hacer el trabajo.

Primero encuentre su carpeta Java ejecutando /usr/libexec/java_home. Para mí fue la 1.6.0.jdkversión. Luego ve a su lib/securitysubcarpeta (para mí /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Luego elimine el cacertsarchivo si ya hay uno y busque uno en el sistema con sudo find / -name "cacerts". Encontró varios elementos para mí, en versiones de Xcode u otras aplicaciones que había instalado, pero también en las /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacertsque elegí.

Use ese archivo y cree un enlace simbólico (dentro de la carpeta Java de antes) sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", y debería funcionar.

Tengo ambos: Java de la descarga 2017-001 de Apple ( https://support.apple.com/kb/dl1572 - Supongo que es de allí de donde provienen los certificados correctos) y uno de Oracle instalado en Mac OS X v10.12 (Sierra) .

en ubuntu 14.04 con openjdk 11 de ppa: openjdk-r / ppa esto funcionó para mí:

en java.security cambie el tipo de almacén de claves a

keystore.type=jks

entonces:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

cuando verifique si funcionó, asegúrese de no estar usando ningún demonio con Java antiguo aún ejecutándose (p. ej. --no-daemon opción para gradle)

Este error describe todo muy bien y lo ayudará a comprender lo que está sucediendo https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

En Ubuntu 18.04 necesitaba usar OpenJDK 1.7 para el mantenimiento de un proyecto antiguo. Descargué el paquete binario. Pero cuando ejecuté mi script en él, obtuve el mismo error.

La solución fue eliminar el cacertsarchivo del JDK descargado en la jre/lib/securitycarpeta y luego crearlo como enlace simbólico al cacertsarchivo del sistema en /etc/ssl/certs/java/:

sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts

Es poco probable que esto ayude a cualquier persona, pero ... para cualquiera que ejecute Java 8 desde una imagen Docker en una Raspberry Pi (usando CPU AMD) Obtuve el siguiente Dockerfile para construir y ejecutar con éxito para mí

FROM hypriot/rpi-java
USER root

WORKDIR /usr/build/

RUN /usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

EXPOSE 8080

ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar

ADD ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]