proyecto - java.security.InvalidAlgorithmParameterException: el parámetro trustAnchors debe estar no vacío en Linux, o por qué el almacén de confianza predeterminado está vacío

problemas al ejecutar un jar (13)

Esta pregunta ya tiene una respuesta aquí:

Error - El parámetro trustAnchors debe estar no vacío 32 respuestas

Cuando busca esta excepción en google: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty , aparecen resultados múltiples. Sin embargo, no hay una solución definitiva, solo conjeturas.

El problema surge (en mi caso al menos) cuando trato de usar abrir una conexión a través de SSL. Funciona bien en mi máquina de Windows, pero cuando la despliego a la máquina de Linux (con jre de Sun instalado) falla con la excepción anterior.

El problema es que el almacén de confianza predeterminado del JRE está vacío por algún motivo (tamaño de solo 32 bytes, mientras que es 80 kb en Windows).

Cuando copié mi archivo jre/lib/security/cacerts de windows a linux, funcionó bien.

La pregunta es: ¿por qué el Linux está teniendo una tienda de confianza vacía?

Tenga en cuenta que esto ocurre en una instancia de Amazon EC2, con AMI linux, por lo que podría deberse a algunas políticas de Amazon (creo que Java estaba preinstalado, pero no estoy seguro)

Asegúrese de tener cacerts válidos en JRE / security; de lo contrario, no omitirá el error inválido de TrustAnchors vacío.

En mi instalación de Amazon EC2 Opensuse12, el problema era que el archivo señalado por las cacerts en el directorio de seguridad de JRE no era válido:

$ java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) $ ls -l /var/lib/ca-certificates/ -rw-r--r-- 1 root 363 Feb 28 14:17 ca-bundle.pem $ ls -l /usr/lib64/jvm/jre/lib/security/ lrwxrwxrwx 1 root 37 Mar 21 00:16 cacerts -> /var/lib/ca-certificates/java-cacerts -rw-r--r-- 1 root 2254 Jan 18 16:50 java.policy -rw-r--r-- 1 root 15374 Jan 18 16:50 java.security -rw-r--r-- 1 root 88 Jan 18 17:34 nss.cfg

Así que resolví la instalación de un viejo Opensuse 11 certificados válidos. (¡¡Lo siento por eso!!)

$ ll total 616 -rw-r--r-- 1 root 220065 Jan 31 15:48 ca-bundle.pem -rw-r--r-- 1 root 363 Feb 28 14:17 ca-bundle.pem.old -rw-r--r-- 1 root 161555 Jan 31 15:48 java-cacerts

Entendí que podría usar la herramienta de claves para generar una nueva ( http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html ). Probablemente tendré que hacerlo pronto.

Saludos lellis

El Sun JDK estándar para Linux tiene una absolutamente aceptable cacerts y en general todos los archivos en el directorio especificado. El problema es la instalación que usa.

Esto sucede porque Access Privilege varía de sistema operativo a sistema operativo. La jerarquía de acceso de Windows es diferente de Unix. Sin embargo, esto se puede superar siguiendo estos simples pasos:

Aumente la accesibilidad con AccessController.doPrivileged(java.security.PrivilegedAction subclass)
Establezca su propia subclase java.security.Provider como propiedad de seguridad. a. Security.insertProviderAt (nuevo, 2);
Establezca su Algorythm con Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

He evitado este error (Java 1.6.0 en OSX 10.5.8) al colocar un certificado falso en el almacén de claves, como

keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit

Seguramente la pregunta debería ser "¿Por qué java no puede manejar un almacén de confianza vacío?"

Mi archivo de cacerts estaba totalmente vacío. Lo resolví copiando el archivo cacerts de mi máquina de Windows (es decir, utilizando Oracle Java 7) y lo descargué en mi caja de Linux (OpenJDK).

cd %JAVA_HOME%/jre/lib/security/ scp cacerts mylinuxmachin:/tmp

y luego en la máquina linux

cp /tmp/cacerts /etc/ssl/certs/java/cacerts

Ha funcionado muy bien hasta ahora.

Mi solución en Windows fue ejecutar la ventana de consola como administrador o cambiar la variable de entorno MAVEN_OPTS para usar una ruta de acceso codificada a trust.jks (por ejemplo, ''C: / Users / oddros'') en lugar de ''% USERPROFILE%''. Mi MAVEN_OPTS ahora se ve así:

-Djavax.net.ssl.trustStore=C:/Users/oddros/trust.jks -Djavax.net.ssl.trustStorePassword=changeit

No es la respuesta a la pregunta original, pero al tratar de resolver un problema similar, descubrí que la actualización de Mac OS X a Maverics estropeó la instalación de Java (el cacert en realidad). Elimine sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk y sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk instalar desde http://www.oracle.com/technetwork/java/javase/downloads/index.html

Obtengo el mismo error en mi máquina con Windows 7 cuando los permisos en mi archivo cacerts en mi carpeta C: / Program Files / Java / jdk1.7.0_51 / jre / lib / security no están configurados correctamente.

Para resolver el problema, permito a los usuarios de SERVICE e INTERACTIVE tener todos los permisos de modificación en las cacerts, excepto "permisos de cambio" y "tomar posesión" (en Configuración avanzada, en Propiedades de seguridad). Supongo que permitir que estos servicios lean y escriban atributos extendidos puede tener algo que ver con que el error desaparezca.

Puedo generar este error estableciendo la propiedad del sistema trustStore en un archivo jks perdido. Por ejemplo

System.setProperty("javax.net.ssl.keyStore", "C:/keystoreFile.jks"); System.setProperty("javax.net.ssl.keyStorePassword", "mypassword"); System.setProperty("javax.net.ssl.trustStore", "C:/missing-keystore.jks"); System.setProperty("javax.net.ssl.trustStorePassword", "mypassword");

Este código no genera una excepción FileNotFound por algún motivo, sino exactamente la excepción InvalidAlgorithmParameter enumerada anteriormente.

Es una respuesta tonta, pero puedo reproducirme.

Recibí este error en Ubuntu. Vi que / usr / lib / jvm / java-8-openjdk-amd64 / jre / lib / security / cacerts era un enlace roto a / etc / ssl / certs / java / cacerts. Eso me llevó a este error: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302 El archivo README para ca-certificates-java finalmente mostró la solución actual:

correr

update-ca-certificates -f

apt-get install ca-certificates-java no funcionó para mí. Simplemente lo marcó como manualmente instalado.

Si esto le sucede con una instalación de OpenJDK en Mac OS X (a diferencia de Linux), y tiene el Mac OS X Java oficial (es decir, el último Java 6) instalado a través de la Actualización de software, puede hacer esto:

cd $OPENJDK_HOME/Contents/Home/jre/lib/security ln -s /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries

donde $OPENJDK_HOME es el directorio raíz de su instalación de OpenJDK, generalmente OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk . Esto es idéntico a la forma en que las instalaciones oficiales de Java en Mac OS X adquieren estos archivos; también los vinculan simbólicamente con esos paquetes de sistema. Works para Lion, no estoy seguro de las versiones anteriores del sistema operativo.

Tenía el mismo problema en Ubuntu 14.10 con java-8-oracle instalado.

Se resolvió la instalación del paquete ca-certificates-java:

sudo apt-get install ca-certificates-java

Tiene el mismo problema. Se resolvió instalando el paquete de certificado ca de Mozilla:

$ zypper in ca-certificates-mozilla The following NEW package is going to be installed: ca-certificates-mozilla 1 new package to install. Retrieving package ca-certificates-mozilla-1.85-8.8.1.noarch (1/1), 143.7 KiB (239.1 KiB unpacked) Retrieving: ca-certificates-mozilla-1.85-8.8.1.noarch.rpm.....................[done] Installing: ca-certificates-mozilla-1.85-8.8.1 ...............................[done] Additional rpm output: Updating certificates in /etc/ssl/certs... 144 added, 0 removed. creating /var/lib/ca-certificates/ca-bundle.pem ... creating /var/lib/ca-certificates/java-cacerts ... 144 added, 0 removed. $ ll /var/lib/ca-certificates/ total 392 drwxr-xr-x 2 root root 4096 Apr 26 07:25 ./ drwxr-xr-x 30 root root 4096 Apr 25 15:00 ../ -rw-r--r-- 1 root root 220196 Apr 26 07:25 ca-bundle.pem -rw-r--r-- 1 root root 161555 Apr 26 07:25 java-cacerts

$ cat /etc/SuSE-release openSUSE 12.2 (x86_64) VERSION = 12.2 CODENAME = Mantis $ java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)