hipoteca.seguranca.InvalidAlgorithmParameterException: o parâmetro trustAnchors deve ser não-vazio no Linux, ou porque é que o truststore por omissão está vazio [duplicado]

Corre

update-ca-certificates -f

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

Certamente a questão deve ser: "porque é que java não consegue lidar com uma loja vazia?"

Posso gerar este erro ao configurar a system property trustStore para um ficheiro JKS em falta. Por exemplo

    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 não gera uma excepção de ficheiro não encontrado por alguma razão, mas exactamente a excepção InvalidAlgorithmParameter listada acima.

A minha solução no Windows era executar a janela da consola como Administrador ou alterar a variável de ambiente MAVEN_OPTS para usar um caminho com código rígido para confiar.jks (e.g. "C:\Users\oddros (') em vez de "%de lucro do utilizador". O meu MAVEN_OPTS agora parece-se com isto:

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

Tinha o mesmo problema no Ubuntu 14.10 com o java-8-oracle instalado.

Resolvido a instalação dos certificados ca-java package:

sudo apt-get install ca-certificates-java

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

E depois na máquina linux

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

Se isto lhe acontecer com uma instalação OpenJDK no Mac OS X (em oposição ao Linux), e tiver o Mac OS X Java oficial (ou seja, o mais recente Java 6) instalado através da actualização do Software, pode simplesmente fazer isto:

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 

Onde $OPENJDK_HOME é o directório raiz da sua instalação OpenJDK, tipicamente OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk. Isto é idêntico à forma como as instalações oficiais Java no Mac OS X adquirem esses arquivos-eles também simplesmente os ligam symlink a partir desses pacotes do sistema. Trabalha para o Lion, não é certo para versões anteriores do O.

Certifique-se de que tem cacerts válidos no JRE/security, caso contrário não irá ignorar o erro do trustAnchors vazio inválido.

Na minha instalação Amazon EC2 Opensuse12, o problema era que o ficheiro apontado pelos cacerts no directório de segurança JRE era invá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

$ 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

Relativamente a: lellis

Tenho o mesmo problema. Resolveu-o instalando o pacote de certificados ca do 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

P. S.

$ 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)

1. aumentar a acessibilidade com AccessController.doPrivileged(java.security.PrivilegedAction subclass)
2. defina a sua própria subclasse como propriedade de segurança. seguranca.insertProviderAt (novo , 2);
3. Ajuste o seu algoritmo com Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

Para resolver o problema, permito que o serviço e os utilizadores interactivos tenham todas as permissões de modificação nos cacerts excepto "mudar as permissões" e "tomar posse" (das configurações avançadas, nas propriedades de segurança). Presumo que permitir a estes serviços ler e escrever atributos alargados pode ter algo a ver com o erro desaparecer.