Erro - o parâmetro trustAnchors deve estar não vazio

Estou tentando configurar meu email no Jenkins / Hudson e recebo constantemente o erro:

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

Vi muitas informações on-line sobre o erro, mas não consegui trabalhar. Estou usando o JDK da Sun no Fedora Linux (não o OpenJDK).

Aqui estão algumas coisas que eu tentei. Tentei seguir os conselhos deste post , mas copiar as cacerts do Windows para minha caixa do Fedora que hospedava Jenkins não funcionou. Tentei seguir este guia enquanto tentava configurar o Gmail como meu servidor SMTP, mas também não funcionou. Também tentei baixar e mover esses arquivos cacert manualmente e movê-los para minha pasta Java usando uma variação dos comandos neste guia .

Estou aberto a sugestões, pois estou preso no momento. Consegui fazê-lo funcionar em um servidor Windows Hudson, mas estou com dificuldades no Linux.

Essa mensagem bizarra significa que o armazenamento confiável que você especificou foi:

• esvaziar,
• não encontrado ou
• não pôde ser aberto (devido a permissões de acesso, por exemplo).

Veja também a resposta de @ AdamPlumb abaixo .

Para depurar esse problema (escrevi sobre ele aqui ) e entender qual armazenamento confiável está sendo usado, você pode adicionar a propriedade javax.net.debug = all e filtrar os logs sobre o armazenamento confiável. Você também pode jogar com a propriedade javax.net.ssl.trustStore para especificar um armazenamento confiável específico. Por exemplo :

    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

No Ubuntu 18.04 , esse erro tem uma causa diferente (JEP 229, alterne do jksformato padrão de keystore para o pkcs12formato e a geração de arquivos cacerts do Debian usando o padrão para novos arquivos) e solução 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

Status (07/08/2018) , o bug foi corrigido no Ubuntu Bionic LTS 18.04.1 e Ubuntu Cosmic 18.10.

🗹 Ubuntu 1770553: back-end [SRU] ca-certificates-java da cosmic (20180413ubuntu1)

176 Ubuntu 1769013: Por favor, mescle ca-certificate-java 20180413 (main) do Debian unstable (main)

🗹 Ubuntu 1739631: A nova instalação com o JDK 9 não pode usar o arquivo de armazenamento de chaves cacerts PKCS12 gerado

🗹 Imagem do docker-library 145: 9-jdk tem problemas de SSL

🗹 Debian 894979: ca-certificates-java: não funciona com o OpenJDK 9, os aplicativos falham com InvalidAlgorithmParameterException: o parâmetro trustAnchors deve estar vazio

🗹 JDK-8044445: JEP 229: criar keystores PKCS12 por padrão

🖺 JEP 229: criar PKCS12 por padrão

Se o problema persistir após esta solução alternativa, convém verificar se você está realmente executando a distribuição Java que acabou de corrigir.

$ which java
/usr/bin/java

Você pode definir as alternativas Java para 'auto' com:

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

Você pode verificar novamente a versão Java que está executando:

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

Também existem soluções alternativas, mas elas têm seus próprios efeitos colaterais, que exigirão manutenção futura extra, sem nenhum retorno.

A próxima melhor solução alternativa é adicionar a linha

javax.net.ssl.trustStorePassword=changeit

para os arquivos

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

o que existir.

A terceira solução menos problemática é alterar o valor de

keystore.type=pkcs12

para

keystore.type=jks

nos arquivos

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

o que existir, remova o cacertsarquivo e gere-o novamente da maneira descrita na última linha do script de solução alternativa na parte superior da postagem.

Isso corrigiu o problema para mim no Ubuntu:

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

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

ca-certificates-java não é uma dependência no Oracle JDK / JRE, portanto, isso deve ser explicitamente instalado.

No Ubuntu 18.04, a causa raiz é um conflito entre o openjdk-11-jdk (que é o padrão) e outros pacotes, dependendo dele. Ele já foi corrigido no Debian e será incluído no Ubuntu em breve. Enquanto isso, a solução mais simples é rebaixar seu java para a versão 8. Outras soluções empregandoca-certificates-java são muito mais complicadas.

Primeiro remova pacotes conflitantes:

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

Verifique se você removeu com êxito todos os pacotes relacionados:

sudo update-alternatives --config java

O sistema solicitará que não haja Java disponível para configuração , caso contrário, essa solução alternativa falhará .

Em seguida, reinstale os pacotes necessários:

sudo apt-get install openjdk-8-jdk

O EJP basicamente respondeu à pergunta (e eu sei que isso tem uma resposta aceita), mas lidei com essa pegadinha e queria imortalizar minha solução.

Eu tive o InvalidAlgorithmParameterExceptionerro em um Jira hospedado servidor que eu havia configurado anteriormente para acesso somente SSL. O problema foi que eu havia configurado meu keystore no formato PKCS # 12, mas meu armazenamento confiável estava no formato JKS.

No meu caso, editei meu server.xmlarquivo para especificar o keystoreType para PKCS, mas não especifiquei o truststoreType, portanto, o padrão é o que seja o keystoreType. Especificar o truststoreType explicitamente como o JKS resolveu para mim.

Corri para esta solução a partir da postagem do blog Corrigindo o problema trustAnchors ao executar o OpenJDK 7 no OS X :

Corrigindo o problema trustAnchors ao executar o OpenJDK 7 no OS X. Se você estiver executando o OpenJDK 7 no OS X e viu esta exceção:

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

Há uma solução simples. Basta vincular o mesmo arquivo cacerts que o JDK 1.6 da Apple usa:

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

Você precisa fazer isso para todas as versões do OpenJDK instaladas. Apenas mude -v 1.7para a versão que você deseja corrigir. Execute /usr/libexec/java_home -Vpara ver todos os JREs e JDKs que você instalou.

Talvez o pessoal do OpenJDK possa adicionar isso aos scripts de instalação.

No Ubuntu 12.10 (Quantal Quetzal) ou posterior, os certificados são mantidos no pacote ca-certificates-java . O uso -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsirá buscá-los, independentemente do JDK que você estiver usando.

Corri para esse problema exato no OS X, usando o JDK 1.7, depois de atualizar para o OS X v10.9 (Mavericks). A correção que funcionou para mim foi simplesmente reinstalar a versão Apple do Java, disponível em http://support.apple.com/kb/DL1572 .

Eu corri

sudo update-ca-certificates -f

para criar um arquivo de certificado e, em seguida:

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

Eu estava de volta aos negócios, obrigado pessoal. É uma pena que não esteja incluído na instalação, mas cheguei lá no final.

O erro diz que o sistema não pode encontrar o truststore no caminho fornecido com o parâmetro javax.net.ssl.trustStore.

No Windows, copiei o cacertsarquivo jre/lib/securitypara o diretório de instalação do Eclipse (mesmo local que o eclipse.iniarquivo) e adicionei as seguintes configurações em eclipse.ini:

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

Eu tive alguns problemas com o caminho para as cacerts (a variável de ambiente% java_home% é de alguma forma substituída), então usei essa solução trivial.

A idéia é fornecer um caminho válido para o arquivo de armazenamento confiável - o ideal seria usar um caminho relativo. Você também pode usar um caminho absoluto.

Para garantir que o tipo de loja seja JKS, execute o seguinte comando:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Remover o pacote ca-certificate-java e instalá-lo novamente funcionou para mim ( Ubuntu MATE 17.10 (Artful Aardvark)).

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

sudo apt-get install ca-certificates-java

Obrigado, jdstrand: Comentário 1 para o bug 983302, Re: ca-certificate-java falha ao instalar o Java cacerts no Oneiric Ocelot .

Eu tive muitos problemas de segurança após atualizar para o OS X v10.9 (Mavericks):

• Problema de SSL com o Amazon AWS
• Par não autenticado com Maven e Eclipse
• trustAnchors parâmetro não deve estar vazio

Apliquei esta atualização do Java e ela corrigiu todos os meus problemas: http://support.apple.com/kb/DL1572?viewlocale=en_US

Eu esperava coisas assim, sendo que eu uso uma JVM alternativa no meu Talend Open Studio (o suporte existe no momento apenas até o JDK 1.7). Eu uso 8 para fins de segurança ... de qualquer maneira

• Atualize seu armazenamento de certificados:

  sudo update-ca-certificates -f

então

• adicione um novo valor nos seus parâmetros de inicialização

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

Para mim, a segunda entrada funcionou. Acho que, dependendo da versão do Talend Open Studio / TEnt + JVM, ele tem um nome de parâmetro diferente, mas procura o mesmo arquivo de armazenamento de chaves.

Para mim, isso foi causado pela falta de uma TrustCertEntry no armazenamento confiável.

Para testar, use:

keytool -list -keystore keystore.jks

Isso me dá:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Embora meu PrivateKeyEntry contenha uma CA, ele precisa ser importado separadamente :

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

Ele importa o certificado e, em seguida, a nova execução keytool -list -keystore keystore.jksagora fornece:

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>

Agora, ele possui um confiávelCertEntry e o Tomcat será iniciado com êxito.

Alguns lançamentos de fornecedores do OpenJDK causaram isso ao ter um cacertsarquivo vazio distribuído com o binário. O bug é explicado aqui: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Você pode copiar para adoptOpenJdk8\jre\lib\security\cacertso arquivo de uma instalação antiga, comoc:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts .

A versão com bug do AdoptOpenJDK é https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Se você experimentar isso no Ubuntu com JDK9 e Maven, poderá adicionar esta opção JVM - primeiro verifique se o caminho existe:

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

Se o arquivo estiver ausente, tente instalar o ca-certificates-java como alguém observou:

sudo apt install ca-certificates-java

Eu tive essa mensagem de erro no Java 9.0.1 no Linux. Isso ocorreu devido a um bug conhecido do JDK, onde o arquivo cacerts está vazio no pacote binário .tar.gz (baixado de http://jdk.java.net/9/ ).

Consulte o parágrafo "problemas conhecidos" das Notas da Versão do JDK 9.0.1 , dizendo "TLS não funciona por padrão no OpenJDK 9".

No Debian / Ubuntu (e provavelmente em outras derivadas), uma solução simples é substituir o arquivo cacerts pelo arquivo do pacote "ca-certificates-java":

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

No Red Hat Linux / CentOS, você pode fazer o mesmo no pacote "ca-certificates":

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

Eu tive esse problema ao tentar usar o Maven 3, depois de atualizar o Ubuntu 16.04 LTS (Xenial Xerus) para o Ubuntu 18.04 LTS (Bionic Beaver).

A verificação de / usr / lib / jvm / java-8-oracle / jre / lib / security mostrou que meu arquivo cacerts era um link simbólico apontando para /etc/ssl/certs/java/cacerts .

Eu também tinha um arquivo com nome suspeito cacerts.original.

Eu mudei o nome cacerts.originalpara cacerts, e isso corrigiu o problema.

Também encontrei isso no OS X após atualizar o OS X v10.9 (Mavericks), quando o antigo Java 6 estava sendo usado e tentei acessar uma URL HTTPS. A solução foi o inverso de Peter Kriens; Eu precisava copiar o cacertsespaço 1.7 para o local vinculado pela versão 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

No meu caso, o arquivo JKS usado no aplicativo cliente foi corrompido. Criei um novo e importei os certificados SSL do servidor de destino. Em seguida, usei o novo arquivo JKS no aplicativo cliente como um armazenamento confiável, como:

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

Fonte: SSL Java e armazenamento de chaves do certificado

Eu uso a ferramenta (KeyStore Explorer) para criar o novo JKS. Você pode baixá-lo neste link, KeyStore Explorer .

Você também pode encontrar esse erro após atualizar para o Spring Boot 1.4.1 (ou mais recente) porque ele traz o Tomcat 8.5.5 como parte de suas dependências.

O problema é devido à maneira como o Tomcat lida com o armazenamento confiável. Se você especificou seu local de armazenamento confiável como o mesmo que seu keystore na configuração do Spring Boot, provavelmente receberá a trustAnchors parameter must be non-emptymensagem ao iniciar o aplicativo.

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

Simplesmente remova a server.ssl.trust-storeconfiguração, a menos que você saiba que precisa, nesse caso, consulte os links abaixo.

Os seguintes problemas contêm mais detalhes sobre o problema:

• O conector HTTPS Tomcat falha ao iniciar com 1.4.1 # 7069
• SSL-client-auth com certificado autoassinado parou de funcionar # 7406
• Atualize para o Tomcat 8.5.5 # 6703

Encontrei esse problema com o SDK do Android SDK. Para mim, esta solução funcionou:

1. Vamos para /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. Substitua cacertporcacert.original

O cacertarquivo era pequeno (22B). Eu instalei a oracle-java8-installerpartir de ppa:webupd8team/java(de acordo com este manual: https://docs.nativescript.org/start/ns-setup-linux ).

Para o registro, nenhuma das respostas aqui funcionou para mim. Minha compilação Gradle começou a falhar misteriosamente com esse erro, incapaz de buscar o HEAD da central do Maven para um arquivo POM específico .

Aconteceu que eu tinha JAVA_HOME definido para minha compilação pessoal do OpenJDK, que eu havia criado para depurar um problema javac. A configuração de volta ao JDK instalado no meu sistema foi corrigida.

No Red Hat Linux, resolvi esse problema importando os certificados para /etc/pki/java/cacerts.

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

Você precisa adicionar as duas linhas acima ao seu código. Não é possível encontrar o armazenamento confiável.

Eu enfrentei esse problema ao executar um conjunto específico de Android para testar no Ubuntu 14.04 (Trusty Tahr). Duas coisas funcionaram para mim, como sugerido por shaheen:

sudo update-ca-certificates -f

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

Nenhuma das soluções que encontrei na Internet funcionou, mas uma versão modificada da resposta de Peter Kriens parece fazer o trabalho.

Primeiro encontre sua pasta Java executando /usr/libexec/java_home. Para mim foi a 1.6.0.jdkversão. Em seguida, vá para a lib/securitysubpasta (para mim/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security ).

Em seguida, exclua o cacertsarquivo se já houver um e procure um no sistema com sudo find / -name "cacerts". Ele encontrou vários itens para mim, nas versões do Xcode ou outros aplicativos que eu havia instalado, mas também nos /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacertsquais eu escolhi.

Use esse arquivo e faça um link simbólico para ele (enquanto estava dentro da pasta Java de antes) sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", e ele deve funcionar.

Eu tenho os dois - Java do download da Apple 2017-001 ( https://support.apple.com/kb/dl1572 - presumo que sejam esses os certificados corretos) e o Oracle instalado no Mac OS X v10.12 (Sierra) .

no ubuntu 14.04 com o openjdk 11 do ppa: openjdk-r / ppa funcionou para mim:

em java.security, altere o tipo de keystore para

keystore.type=jks

então:

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

ao verificar se funcionou, verifique se não está usando nenhum daemon com o java antigo ainda em execução (por exemplo, --no-daemonopção para gradle)

esse bug descreve tudo bem e ajuda você a entender o que está acontecendo https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

No Ubuntu 18.04, eu precisava usar o OpenJDK 1.7 para a manutenção de um projeto antigo. Eu baixei o pacote binário. Mas quando eu executei meu script, recebi o mesmo erro.

A solução foi remover o cacertsarquivo do JDK baixado na jre/lib/securitypasta e, em seguida, criá-lo como link simbólico para o cacertsarquivo de sistemas em /etc/ssl/certs/java/:

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

Uma pequena chance de ajudar alguém, exceto ... para quem executa o Java 8 a partir de uma imagem do Docker em um Raspberry Pi (usando CPU AMD), obtive o seguinte Dockerfile para compilar e executar com êxito para mim

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"]