java - extended - Error: el parámetro trustAnchors no debe estar vacío
extended email notification jenkins example (30)
Estoy intentando configurar mi correo electrónico en Jenkins / Hudson, y recibo constantemente 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 ninguna funcione. Estoy usando el JDK de Sun en Fedora Linux (no OpenJDK).
Aquí hay algunas cosas que he intentado. Intenté seguir los consejos de esta post , pero copiar los cacerts de Windows a mi caja de Fedora que aloja a Jenkins no funcionó. Intenté seguir esta guía porque 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 de Java usando una variación de los comandos en esta guía .
Estoy abierto a cualquier sugerencia ya que actualmente estoy atascado. Lo hice funcionar desde un servidor de Windows Hudson, pero estoy teniendo problemas con Linux.
Básicamente, EJP respondió a la pregunta (y me doy cuenta de que esta tiene una respuesta aceptada), pero acabo de resolver este problema de borde y quise inmortalizar mi solución.
Recibí el error InvalidAlgorithmParameterException en un servidor Jira alojado que previamente había configurado 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 archivo server.xml para especificar el tipo de almacén de claves en PKCS, pero no especifiqué el tipo de almacén de confianza, por lo que es el tipo de almacén de claves predeterminado. La especificación de truststoreType explícitamente como JKS lo resolvió por mí.
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 .
Bajo Windows copié el archivo cacerts de jre/lib/security en el directorio de instalación de Eclipse (el mismo lugar que el archivo eclipse.ini ) 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% está de alguna manera sobrescrita), así que utilicé esta solución trivial.
La idea es proporcionar una ruta válida al archivo del almacén de confianza; lo ideal sería utilizar una relativa. También puedes usar un camino absoluto.
Para asegurarse de que el tipo de tienda sea JKS, ejecute el siguiente comando:
keytool -list -keystore cacerts
Keystore type: JKS
Keystore provider: SUN
En Ubuntu 12.10 (Quantal Quetzal) o posterior, los certificados se guardan en el paquete ca-certificates-java . El uso de -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts los seleccionará independientemente del JDK que esté usando.
En Ubuntu 18.04 , este error tiene una causa diferente (JEP 229, el cambio del formato predeterminado del almacén de claves pkcs12 formato pkcs12 , y la generación de archivos cacerts de Debian usando el valor predeterminado para los nuevos archivos) y la workaround :
# 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
https://git.mikael.io/mikaelhg/broken-docker-jdk9-cacerts
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 desde cosmic (20180413ubuntu1)
🗹 Ubuntu 1769013: fusione ca-certificados-java 20180413 (principal) desde Debian inestable (principal)
🗹 docker-library 145: la imagen 9-jdk tiene problemas de SSL
🗹 JDK-8044445: JEP 229: Crear almacenes de claves PKCS12 por defecto
🖺 JEP 229: Crear almacenes de claves PKCS12 por defecto
Si el problema continúa después de esta solución, es posible que desee asegurarse de que realmente está ejecutando la distribución Java que acaba de corregir.
$ 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
Puedes 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 hay soluciones alternativas, pero esas tienen sus propios efectos secundarios que requerirán un mantenimiento futuro adicional, sin ningún tipo de 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 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 archivo cacerts y cacerts de la manera descrita anteriormente.
En Red Hat Linux resolví este problema al importar los certificados a /etc/pki/java/cacerts .
En Ubuntu 18.04, la causa raíz es un conflicto entre openjdk-11-jdk (que es el predeterminado) y otros paquetes que dependen de él. Ya se ha corregido en Debian y se incluirá en Ubuntu en breve. Mientras tanto, la solución más sencilla es degradar su Java a la versión 8. Otras soluciones que emplean ca-certificates-java son mucho más complicadas.
Primero elimine los paquetes conflictivos:
sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge
Compruebe el tiempo que eliminó con éxito todos los paquetes relacionados por:
sudo update-alternatives --config java
El sistema le indicará que no hay Java disponible para la configuración , de lo contrario, esta solución falla .
Luego reinstale los paquetes requeridos:
sudo apt-get install openjdk-8-jdk
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 en él. Luego utilicé 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.
Utilizo la herramienta (KeyStore Explorer) para crear el nuevo JKS. Puedes descargarlo desde este enlace, KeyStore Explorer .
En windows10 y openjdk fue causado por tener un archivo de cacerts vacío distribuido con el binario. El error se explica aquí: https://github.com/AdoptOpenJDK/openjdk-build/issues/555
Puede copiar para adoptOpenJdk8/jre/lib/security/cacerts el archivo de una instalación antigua como c:/Program Files/Java/jdk1.8.0_192/jre/lib/security/cacerts .
La versión de buggy de AdoptOpenJDK es https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip
Encontré este problema con el SDK de Android sdkmanager. Para mí esta solución funcionó:
- Vaya a / usr / lib / jvm / java-8-oracle / jre / lib / security /
- Reemplace ''cacert'' con ''cacert.original''
El archivo ''cacert'' era pequeño (22B). He instalado el instalador oracle-java8 de ppa: webupd8team / java (de acuerdo con este manual: https://docs.nativescript.org/start/ns-setup-linux ).
Enfrenté el problema al importar un proyecto de Gradle en IntelliJ IDEA 14. Una solución estaba usando una copia local de Gradle en lugar de una envoltura del directorio del proyecto.
Esperaba cosas como esta, ya que utilizo una JVM alternativa en mi Talend Open Studio (el soporte en este momento solo existe hasta JDK 1.7). Yo uso 8 por razones de seguridad ... de todos modos
Actualice su almacén 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.
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 los permisos de acceso, por ejemplo).
Véase también la respuesta de @Adamplumb a continuació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.
He tenido muchos problemas de seguridad después de actualizar a OS X v10.9 (Mavericks):
- Problema SSL con Amazon AWS
- Peer no autenticado con Maven y Eclipse.
-
trustAnchorsparámetrotrustAnchorsno debe estar vacío
Apliqué esta actualización de Java y solucioné todos mis problemas: http://support.apple.com/kb/DL1572?viewlocale=en_US
Me encontré con esta solución de la publicación del blog Arreglando el problema de trustAnchors al ejecutar OpenJDK 7 en OS X :
Solucionar el problema de 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. Solo enlace en el mismo archivo cacerts que usa 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. Solo cambia -v 1.7 a la versión que quieres arreglar. Ejecute /usr/libexec/java_home -V para ver todos los JRE y los JDK que ha instalado.
Quizás los chicos de OpenJDK podrían agregar esto a sus scripts de instalación.
Me encontré con este problema exacto en OS X, utilizando 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 Apple de Java, disponible en http://support.apple.com/kb/DL1572 .
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 mi fue la versión 1.6.0.jdk . Luego vaya a su subcarpeta lib/security (para mí /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security ).
Luego elimine el archivo cacerts 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 tenía instaladas, pero también en /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts que elegí.
Use ese archivo y haga un enlace simbólico (mientras esté dentro de la carpeta de Java anterior), sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts" , y Deberia trabajar.
Tengo ambas: Java de la descarga de 2017-001 de Apple ( https://support.apple.com/kb/dl1572 - Supongo que de ahí provienen los certificados correctos) y la de Oracle instalada en Mac OS X v10.12 (Sierra) .
Otra razón para esto es que es realmente un error válido. Algunos infames puntos de conexión Wi-Fi se mezclarán con los certificados y el hombre en el medio te atacará para hacer quién sabe qué (¡huir!).
Algunos empleadores grandes harán este mismo truco, especialmente en zonas de red sensibles para que puedan monitorear todo el tráfico cifrado (no es muy bueno desde la perspectiva del usuario final, pero puede haber buenas razones para esto).
Para el registro, ninguna de las respuestas aquí funcionó para mí. Mi compilación de Gradle comenzó a fallar misteriosamente con este error, al no poder obtener HEAD de la central Maven para un archivo POM particular.
Resultó que tenía JAVA_HOME configurado para mi propia compilación personal de OpenJDK, que había creado para depurar un problema de javac. Configurándolo de nuevo al JDK instalado en mi sistema lo arregló.
Para mí, fue causado por la falta de un TrustedCertEntry en el almacén de confianza.
Para probar, utilice:
keytool -list -keystore keystore.jks
Me da:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
cert-alias, 31-Jul-2017, PrivateKeyEntry
A pesar de que mi PrivateKeyEntry contiene una CA , debía importarse por separado :
keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks
Importa el certificado, y luego vuelve a ejecutar keytool -list -keystore keystore.jks ahora da:
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 trustCertEntry, y Tomcat se iniciará correctamente.
Quitar el paquete ca-certificate-java e instalarlo nuevamente me funcionó ( 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-certificate-java no puede instalar cacerts de Java en Oneiric Ocelot .
Recibí este error al usar un almacén de confianza que se exportó usando una herramienta de herramienta JDK de IBM Websphere en formato # PKCS12 y al intentar comunicarme sobre SSL usando ese archivo en un JRE de Oracle.
Mi solución fue ejecutar un IBM JRE o convertir el almacén de confianza a JKS utilizando una herramienta de IBM Websphere, por lo que pude ejecutarlo en un Oracle JRE.
Si experimenta esto en Ubuntu con JDK9 y Maven, puede agregar esta opción JVM: primero verifique si existe la ruta:
-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
Si falta el archivo, intente instalar el certificado de ca-java como alguien anotó:
sudo apt install ca-certificates-java
También encontré esto en OS X después de actualizar OS X v10.9 (Mavericks), cuando se estaba utilizando el antiguo Java 6 e intenté acceder a una URL de HTTPS. La solución fue la inversa de Peter Kriens; Necesitaba copiar los cacerts del 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
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 el almacén de confianza. Si ha especificado la ubicación de su almacén de confianza como la de su almacén de claves en la configuración de Spring Boot, es probable que obtenga el trustAnchors parameter must be non-empty cuando inicie la aplicación.
server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks
Simplemente elimine la server.ssl.trust-store 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:
Tuve este mensaje de error en Java 9.0.1 en Linux. Se debió 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 versión de JDK 9.0.1 , que dice que "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-certificate-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 de "certificados de ca":
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).
Al revisar / usr / lib / jvm / java-8-oracle / jre / lib / security se mostró que mi archivo de cacerts era un enlace simbólico que apunta a /etc/ssl/certs/java/cacerts .
También tuve un archivo sospechoso llamado cacerts.original .
cacerts.original nombre de cacerts.original a cacerts , y eso solucionó el problema.
corrí
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 llegué al final.
Enfrenté este problema mientras ejecutaba una suite 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
System.setProperty("javax.net.ssl.trustStore", "C://Users//user-id//Desktop//tomcat//cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");
Tienes que agregar las dos líneas anteriores a tu código. No es capaz de encontrar el almacén de confianza.