Edit: - Tentou formatar a pergunta e aceitar a resposta de maneira mais apresentável no meu Blog

Aqui está a questão original.

Estou recebendo este erro:

mensagem detalhada sun.security.validator.ValidatorException: falha na construção do caminho PKIX:
sun.security.provider.certpath.SunCertPathBuilderException: não foi possível encontrar o caminho de certificação válido para o destino solicitado

causa javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: falha na construção do caminho PKIX: sun.security.provider.certpath.SunCertPathBuilderException: não foi possível encontrar o caminho de certificação válido para o destino solicitado

Estou usando o Tomcat 6 como servidor da web. Eu tenho dois aplicativos da web HTTPS instalados em Tomcats diferentes em portas diferentes, mas na mesma máquina. Diga App1(port 8443)e App2(port 443). App1se conecta a App2. Quando se App1conecta App2, recebo o erro acima. Sei que este é um erro muito comum, por isso encontrei muitas soluções em diferentes fóruns e sites. Eu tenho a entrada abaixo em server.xmlambos os Tomcats:

keystoreFile="c:/.keystore" 
keystorePass="changeit"

Todo site diz o mesmo motivo pelo qual o certificado fornecido pelo app2 não está no repositório confiável da app1 jvm. Isso parece ser verdade também quando tentei acessar a mesma URL no navegador IE, funciona (com o aquecimento, existe um problema com o certificado de segurança deste site. Aqui digo continuar neste site). Mas quando o mesmo URL é atingido pelo cliente Java (no meu caso), recebo o erro acima. Então, para colocá-lo no armazenamento confiável, tentei estas três opções:

Opção 1

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Opção2 Configuração abaixo na variável de ambiente

CATALINA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Opção3 Configuração abaixo na variável de ambiente

JAVA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Mas nada funcionou .

O que finalmente funcionou foi a execução da abordagem Java sugerida em Como lidar com certificados SSL inválidos com o Apache HttpClient? por Pascal Thivent, ou seja, executando o programa InstallCert.

Mas essa abordagem é adequada para a configuração do devbox, mas não posso usá-la no ambiente de produção.

Estou perguntando por três abordagens mencionadas acima não funcionou quando eu mencionei os mesmos valores em server.xmlde app2valores de servidores e mesmo no truststore por definição

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore") and System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

no app1programa.

Para mais informações, é assim que estou fazendo a conexão:

URL url = new URL(urlStr);

URLConnection conn = url.openConnection();

if (conn instanceof HttpsURLConnection) {

  HttpsURLConnection conn1 = (HttpsURLConnection) url.openConnection();

  conn1.setHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return true;
    }
  });

  reply.load(conn1.getInputStream());

Você precisa adicionar o certificado para App2 ao arquivo de armazenamento confiável da JVM usada localizada em %JAVA_HOME%\lib\security\cacerts.

Primeiro, você pode verificar se o seu certificado já está no armazenamento confiável executando o seguinte comando: keytool -list -keystore "%JAVA_HOME%/jre/lib/security/cacerts"(você não precisa fornecer uma senha)

Se o seu certificado estiver ausente, você pode obtê-lo baixando-o com o navegador e adicioná-lo ao armazenamento confiável com o seguinte comando:

keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>

Após a importação, você pode executar o primeiro comando novamente para verificar se o seu certificado foi adicionado.

Informações da Sun / Oracle podem ser encontradas aqui .

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: falha na construção do caminho PKIX: sun.security.provider.certpath.SunCertPathBuilderException: não foi possível encontrar o caminho de certificação válido para o destino solicitado

• Quando recebi o erro, tentei pesquisar no Google o significado da expressão e descobri que esse problema ocorre quando um servidor altera o certificado SSL HTTPS e nossa versão mais antiga do java não reconhece a autoridade de certificação raiz (CA) .

• Se você pode acessar a URL HTTPS no seu navegador, é possível atualizar o Java para reconhecer a CA raiz.

• No seu navegador, acesse a URL HTTPS que Java não pôde acessar. Clique na cadeia de certificados HTTPS (existe um ícone de cadeado no Internet Explorer), clique no cadeado para visualizar o certificado.

• Vá para "Detalhes" do certificado e "Copiar para arquivo". Copie-o no formato Base64 (.cer) . Ele será salvo na sua área de trabalho.

• Instale o certificado ignorando todos os alertas.

• Foi assim que reuni as informações do certificado da URL que estava tentando acessar.

Agora eu tive que fazer minha versão java para conhecer o certificado, para que ele não se recuse a reconhecer a URL. A esse respeito, devo mencionar que pesquisei que as informações do certificado raiz permanecem por padrão no local \ jre \ lib \ security do JDK e a senha padrão para acessar é: changeit.

Para visualizar as informações de cacerts, a seguir estão os procedimentos a seguir:

• Clique no botão Iniciar -> Executar

• Digite cmd. O prompt de comando é aberto (pode ser necessário abri-lo como administrador).

• Vá para o seu Java/jreX/bindiretório

• Digite o seguinte

keytool -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Ele fornece a lista dos certificados atuais contidos no keystore. Parece algo como isto:

C: \ Documents and Settings \ NeelanjanaG> keytool -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Digite a senha do keystore: changeit

Tipo de armazenamento de chaves: jks

Fornecedor de keystore: SUN

Seu keystore contém 44 entradas

verisignclass3g2ca, 26 de março de 2004, trustCertEntry,

Impressão digital do certificado (MD5): A2: 33: 9B: 4C: 74: 78: 73: D4: 6C: E7: C1: F3: 8D: CB: 5C: E9

entrustclientca, 9 de janeiro de 2003, trustCertEntry,

Impressão digital do certificado (MD5): 0C: 41: 2F: 13: 5B: A0: 54: F5: 96: 66: 2D: 7E: CD: 0E: 03: F4

thawtepersonalbasicca, 13 de fevereiro de 1999, trustCertEntry,

Impressão digital do certificado (MD5): E6: 0B: D2: C9: CA: 2D: 88: DB: 1A: 71: 0E: 4B: 78: EB: 02: 41

addtrustclass1ca, 1 de maio de 2006, trustCertEntry,

Impressão digital do certificado (MD5): 1E: 42: 95: 02: 33: 92: 6B: B9: 5F: C0: 7F: DA: D6: B2: 4B: FC

verisignclass2g3ca, 26 de março de 2004, trustCertEntry,

Impressão digital do certificado (MD5): F8: BE: C4: 63: 22: C9: A8: 46: 74: 8B: B8: 1D: 1E: 1E: 4A: 2B: F6

• Agora eu tinha que incluir o certificado instalado anteriormente nos cacerts.

• Para isso, é o seguinte o procedimento:

keytool –import –noprompt –custcacerts –alias ALIASNAME -file FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -storepass PASSWORD

Se você estiver usando o Java 7:

keytool –importcert –trustcacerts –alias ALIASNAME - arquivo PATH_TO_FILENAME_OF_THE_INSTALLED_CERTIFICATE - keystore PATH_TO_CACERTS_FILE - storepass changeit

• Ele adicionará as informações do certificado ao arquivo cacert.

É a solução que encontrei para a exceção mencionada acima !!

Como trabalhar no Tomcat 7

Eu queria oferecer suporte a um certificado autoassinado em um aplicativo Tomcat, mas o seguinte trecho não funcionou

import java.io.DataOutputStream;
import java.net.HttpURLConnection;
import java.net.URL;

public class HTTPSPlayground {
    public static void main(String[] args) throws Exception {

        URL url = new URL("https:// ... .com");
        HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();

        httpURLConnection.setRequestMethod("POST");
        httpURLConnection.setRequestProperty("Accept-Language", "en-US,en;q=0.5");
        httpURLConnection.setDoOutput(true);
        DataOutputStream wr = new DataOutputStream(httpURLConnection.getOutputStream());

        String serializedMessage = "{}";
        wr.writeBytes(serializedMessage);
        wr.flush();
        wr.close();

        int responseCode = httpURLConnection.getResponseCode();
        System.out.println(responseCode);
    }
}

Foi isso que resolveu meu problema:

1) Baixe o .crtarquivo

echo -n | openssl s_client -connect <your domain>:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ~/<your domain>.crt

• substitua <your domain>pelo seu domínio (por exemplo jossef.com)

2) Aplique o .crtarquivo no cacertsarmazenamento de certificados do Java

keytool -import -v -trustcacerts -alias <your domain> -file ~/<your domain>.crt -keystore <JAVA HOME>/jre/lib/security/cacerts -keypass changeit -storepass changeit

• substitua <your domain>pelo seu domínio (por exemplo jossef.com)
• substitua <JAVA HOME>pelo seu diretório home java

3) hackear

Embora tenha instalado meu certificado nos Javaarmazenamentos de certificados padrão do Tomcat , o Tomcat ignora isso (parece que não está configurado para usar os armazenamentos de certificados padrão do Java).

Para hackear isso, adicione o seguinte em algum lugar no seu código:

String certificatesTrustStorePath = "<JAVA HOME>/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);

// ...

No meu caso, o problema era que o servidor da web estava enviando apenas o certificado e a CA intermediária, não a CA raiz. A adição desta opção da JVM resolveu o problema:-Dcom.sun.security.enableAIAcaIssuers=true

O suporte para o método de acesso de solicitadores da extensão Acesso à informação da autoridade está disponível. Ele está desativado por padrão para compatibilidade e pode ser ativado configurando a propriedade do sistema com.sun.security.enableAIAcaIssuerspara o valor true.

Se definida como true, a implementação do CertPathBuilder da Sun no PKIX usa as informações na extensão AIA de um certificado (além das CertStores especificadas) para encontrar o certificado de CA de emissão, desde que seja um URI do tipo ldap, http ou ftp.

Fonte

Outro motivo pode ser uma versão desatualizada do JDK. Eu estava usando o jdk versão 1.8.0_60, basta atualizar a última versão para resolver o problema de certificado.

Meu arquivo de cacerts estava totalmente vazio. Resolvi isso copiando o arquivo cacerts da minha máquina Windows (que usa o Oracle Java 7) e scp'd na minha caixa Linux (OpenJDK).

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

e depois na máquina linux

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

Até agora, funcionou muito bem.

Para mim, esse erro apareceu também ao tentar conectar-se a um processo atrás de um proxy reverso NGINX que estava manipulando o SSL.

Acabou que o problema era um certificado sem toda a cadeia de certificados concatenada. Quando adicionei certificados intermediários, o problema foi resolvido.

Espero que isto ajude.

Usando o Tomcat 7 no Linux, isso fez o truque.

String certificatesTrustStorePath = "/etc/alternatives/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

No Linux, $JAVA_HOMEnem sempre é configurado, mas geralmente /etc/alternatives/jreaponta para$JAVA_HOME/jre

O código abaixo funciona para mim:

import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.X509TrustManager;

public class TrustAnyTrustManager implements X509TrustManager {

public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[] {};
}
}

HttpsURLConnection conn = null;
            URL url = new URL(serviceUrl);
            conn = (HttpsURLConnection) url.openConnection();
             SSLContext sc = SSLContext.getInstance("SSL");  
             sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());  

             conn.setSSLSocketFactory(sc.getSocketFactory());

Eu estava usando jdk1.8.0_171 quando enfrentei o mesmo problema. Tentei as 2 principais soluções aqui (adicionando um certificado usando o keytool e outra solução que possui um hack), mas elas não funcionaram para mim.

Atualizei meu JDK para 1.8.0_181e funcionou como um encanto.

Eu escrevi um pequeno script estúpido do cmd (linha de comando) do win32 (WinXP 32bit testet), que procura todas as versões java nos arquivos de programas e adiciona um certificado a elas. A senha precisa ser o "changeit" padrão ou altere você mesmo no script :-)

@echo off

for /F  %%d in ('dir /B %ProgramFiles%\java') do (
    %ProgramFiles%\Java\%%d\bin\keytool.exe -import -noprompt -trustcacerts -file some-exported-cert-saved-as.crt -keystore %ProgramFiles%\Java\%%d\lib\security\cacerts -storepass changeit
)

pause

Para o MacOS X abaixo, é o comando exato que funcionou para mim, onde eu tive que tentar com duplo hífen na opção 'importcert', que funcionou:

sudo keytool -–importcert -file /PathTo/YourCertFileDownloadedFromBrowserLockIcon.crt -keystore /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/security/cacerts -alias "Cert" -storepass changeit

Para mim, não funcionou a solução reconhecida desta postagem: https://stackoverflow.com/a/9619478/4507034 .

Em vez disso, consegui resolver o problema importando a certificação para as certificações confiáveis ​​da minha máquina.

Passos:

1. Vá para o URL (por exemplo https://localhost:8443/yourpath) onde a certificação não está funcionando.
2. Exporte a certificação conforme descrito na publicação mencionada.
3. Na sua máquina Windows, abra: Manage computer certificates
4. Vá para Trusted Root Certification Authorities->Certificates
5. Importe aqui seu your_certification_name.cerarquivo.

Para o Tomcat em execução no servidor Ubuntu, para descobrir qual Java está sendo usado, use o comando "ps -ef | grep tomcat":

Amostra:

/home/mcp01$ **ps -ef |grep tomcat**
tomcat7  28477     1  0 10:59 ?        00:00:18 **/usr/local/java/jdk1.7.0_15/bin/java** -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx512m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start
1005     28567 28131  0 11:34 pts/1    00:00:00 grep --color=auto tomcat

Em seguida, podemos acessar: cd /usr/local/java/jdk1.7.0_15/jre/lib/security

O arquivo cacerts padrão está localizado aqui. Insira o certificado não confiável nele.

por segurança, não devemos usar certificados autoassinados em nossa implementação. No entanto, quando se trata de desenvolvimento, geralmente precisamos usar ambientes de teste com certificados autoassinados. Tentei corrigir esse problema programaticamente no meu código e falhei. No entanto, a adição do certificado à jre trust-store corrigiu meu problema. Encontre os passos abaixo,

1. Faça o download do certificado do site,

   • Usando o Chrome
   • Usando o Firefox

2. Copie o certificado (ex: cert_file.cer) no diretório $ JAVA_HOME \ Jre \ Lib \ Security

3. Abra o CMD no Administrator e altere o diretório para $ JAVA_HOME \ Jre \ Lib \ Security

4. Importe o certificado para um armazenamento confiável usando o comando abaixo,

keytool -import -alias ca -file cert_file.cer -keystore cacerts -storepass changeit

Se você encontrou um erro dizendo que o keytool não é reconhecível, consulte isso.

Digite sim como abaixo

Confie neste certificado: [Sim]

5. Agora tente executar seu código ou acessar a URL programaticamente usando java.

Atualizar

Se o servidor de aplicativos for o jboss, tente adicionar a propriedade do sistema abaixo

System.setProperty("org.jboss.security.ignoreHttpsHost","true");

Espero que isto ajude!

SOLUÇÃO IMPLANTÁVEL (Alpine Linux)

Para poder corrigir esse problema em nossos ambientes de aplicativos, preparamos os comandos do terminal Linux da seguinte maneira:

cd ~

Gerará arquivo cert no diretório inicial.

apk add openssl

Este comando instala o openssl no Linux alpino. Você pode encontrar comandos adequados para outras distribuições Linux.

openssl s_client -connect <host-dns-ssl-belongs> < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt

Gerou o arquivo cert necessário.

sudo $JAVA_HOME/bin/keytool -import -alias server_name -keystore $JAVA_HOME/lib/security/cacerts -file public.crt -storepass changeit -noprompt

Aplicou o arquivo gerado ao JRE com o programa 'keytool'.

Nota: Substitua seu DNS por<host-dns-ssl-belongs>

Nota2: Observe com cuidado que -nopromptnão solicitará a mensagem de verificação (sim / não) e o -storepass changeitparâmetro desativará o prompt de senha e fornecerá a senha necessária (o padrão é 'changeit'). Essas duas propriedades permitem usar esses scripts nos ambientes de aplicativos, como a construção de uma imagem do Docker.

Nota3 Se você estiver implantando seu aplicativo via Docker, poderá gerar o arquivo secreto uma vez e colocá-lo nos arquivos de projeto do aplicativo. Você não precisará gerá-lo repetidamente.

Eu tenho esse problema tambem.

Tentei quase tudo adicionando o certificado SSL ao .keystore, mas ele não estava funcionando com o Java1_6_x. Para mim, ajudou se começarmos a usar a versão mais recente do Java, Java1_8_x como JVM.

Eu estava tendo esse problema com o Android Studio quando estava atrás de um proxy. Eu estava usando o Crashlytics que tenta carregar o arquivo de mapeamento durante uma compilação.

Adicionei o certificado de proxy ausente ao armazenamento confiável localizado em /Users/[username]/Documents/Android Studio.app/Contents/jre/jdk/Contents/Home/jre/lib/security/cacerts

com o seguinte comando: keytool -import -trustcacerts -keystore cacerts -storepass [password] -noprompt -alias [alias] -file [my_certificate_location]

por exemplo, com a senha padrão do armazenamento confiável keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias myproxycert -file /Users/myname/Downloads/MyProxy.crt

Apenas um pequeno truque. Atualize a URL no arquivo "hudson.model.UpdateCenter.xml" de https para http

<?xml version='1.1' encoding='UTF-8'?>
<sites>
  <site>
    <id>default</id>
    <url>http://updates.jenkins.io/update-center.json</url>
  </site>
</sites>

Quero entrar em cena, já que tenho um ambiente QEMU em que tenho que baixar arquivos em java. Acontece que /etc/ssl/certs/java/cacertsno QEMU há um problema porque não corresponde ao /etc/ssl/certs/java/cacertsambiente do host. O ambiente host está atrás de um proxy da empresa, portanto, o java cacerts é uma versão customizada.

Se você estiver usando um ambiente QEMU, verifique se o sistema host pode acessar os arquivos primeiro. Por exemplo, você pode tentar esse script na máquina host primeiro para ver. Se o script funcionar bem na máquina host, mas não no QEMU, você está tendo o mesmo problema que eu.

Para resolver esse problema, tive que fazer um backup do arquivo original no QEMU, copiar sobre o arquivo no ambiente host para a prisão chroot do QEMU e, em seguida, o java poderia baixar arquivos normalmente no QEMU.

Uma solução melhor seria montar o /etcambiente QEMU; no entanto, não tenho certeza se outros arquivos serão impactados nesse processo. Então decidi usar essa solução feia, mas fácil.

Parece um local tão bom quanto qualquer outro para documentar outro possível motivo para a infame mensagem de erro do PKIX. Depois de passar muito tempo olhando o conteúdo do keystore e do armazenamento confiável e várias configurações de instalação do java, percebi que meu problema era baixo ... um erro de digitação.

O erro de digitação significava que eu também estava usando o keystore como o armazenamento confiável. Como minha CA raiz da empresa não foi definida como um certificado independente no keystore, mas apenas como parte de uma cadeia de certificados, e não foi definida em nenhum outro lugar (por exemplo, cacerts), eu continuava recebendo o erro PKIX.

Depois de um lançamento com falha (esta é uma configuração de prod, estava tudo bem em outro lugar) e dois dias de coçar a cabeça, finalmente vi o erro de digitação, e agora tudo está bem.

Espero que isso ajude alguém.

adicione isso ao seu código:

TrustManager[] trustAllCerts = new TrustManager[]{
           new X509TrustManager() {
               @Override
               public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                   return new X509Certificate[0];
               }

               @Override
               public void checkClientTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }

               @Override
               public void checkServerTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }
           }
       };

       try {
           SSLContext sc = SSLContext.getInstance("SSL");
           sc.init(null, trustAllCerts, new java.security.SecureRandom());
           HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
       } catch (GeneralSecurityException e) {
       }