Error: el parámetro TrustAnchors no debe estar vacío
Estoy intentando 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 logrado que ninguna funcione. Estoy usando JDK de Sun 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 aloja Jenkins no funcionó. Intenté seguir esta guía mientras intentaba 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 estancado. Lo hice funcionar desde un servidor Windows Hudson, pero tengo problemas en Linux.
Este extraño mensaje significa que el almacén de confianza que especificaste era:
- vacío,
- no encontrado, o
- no se pudo abrir debido, por ejemplo, a:
- incorrecto/faltante
trustStorePassword
, o - permisos de acceso a archivos.
- incorrecto/faltante
Vea también la respuesta de @AdamPlumb a continuación .
En Ubuntu 18.04 , este error tiene una causa diferente (JEP 229, cambio del jks
formato predeterminado del almacén de claves al pkcs12
formato y la generación de archivos cacerts de Debian usando el valor predeterminado para archivos nuevos) y una 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 solucionado en Ubuntu Bionic LTS 18.04.1 y Ubuntu Cosmic 18.10.
🗹 Ubuntu 1770553: [SRU] backport ca-certificates-java de cosmic (20180413ubuntu1)
🗹 Ubuntu 1769013: combine ca-certificates-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 cacerts PKCS12 generado
🗹 docker-library 145: la imagen 9-jdk tiene problemas de SSL
🗹 Debian 894979: ca-certificates-java: no funciona con OpenJDK 9, las aplicaciones fallan con InvalidAlgorithmParameterException: el parámetro trustAnchors no debe estar vacío
🗹 JDK-8044445: JEP 229: Crear almacenes de claves PKCS12 de forma predeterminada
🖺 JEP 229: Crear almacenes de claves PKCS12 de forma predeterminada
Si el problema continúa después de esta solución, es posible que desees asegurarte de que realmente estás ejecutando la distribución de Java que acabas de solucionar.
$ which java
/usr/bin/java
Puede configurar las alternativas de Java en 'auto' con:
$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so
Puedes volver a verificar la versión de Java que estás 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 en el 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
cualquiera que exista.
La tercera solución 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 cacerts
archivo y vuelva a generarlo de la manera descrita en la última fila del script de solución en la parte superior de la publicación.
Esto me solucionó el problema en Ubuntu:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
(que se encuentra 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.