Editar: - Intenté formatear la pregunta y acepté la respuesta de una manera más presentable en el mío Blog

Aquí está el problema original.

Recibo este error:

mensaje detallado sun.security.validator.ValidatorException: falló la construcción de la ruta PKIX:
sun.security.provider.certpath.SunCertPathBuilderException: no se pudo encontrar la ruta de certificación válida para el objetivo solicitado

causa javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: falló la construcción de la ruta PKIX: sun.security.provider.certpath.SunCertPathBuilderException: no se pudo encontrar la ruta de certificación válida para el objetivo solicitado

Estoy usando Tomcat 6 como servidor web. Tengo dos aplicaciones web HTTPS instaladas en diferentes Tomcats en diferentes puertos pero en la misma máquina. Di App1(port 8443)y App2(port 443). App1se conecta a App2. Cuando se App1conecta a App2me sale el error anterior. Sé que este es un error muy común, por lo que encontré muchas soluciones en diferentes foros y sitios. Tengo la siguiente entrada server.xmlde ambos Tomcats:

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

Todos los sitios dicen la misma razón por la que el certificado otorgado por app2 no se encuentra en la tienda de confianza de app1 jvm. Esto parece ser cierto también cuando traté de golpear la misma URL en el navegador IE, funciona (con el calentamiento, hay un problema con el certificado de seguridad de este sitio web. Aquí digo que continúe con este sitio web). Pero cuando el cliente Java alcanza la misma URL (en mi caso) obtengo el error anterior. Para ponerlo en el almacén de confianza probé estas tres opciones:

Opción 1

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

Opción 2 Configuración a continuación en la variable de entorno

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

Opción 3 Configuración a continuación en la variable de entorno

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

Pero nada funcionó .

Lo que finalmente funcionó es ejecutar el enfoque Java sugerido en Cómo manejar certificados SSL no válidos con Apache HttpClient? por Pascal Thivent, es decir, ejecutando el programa InstallCert.

Pero este enfoque está bien para la configuración de devbox, pero no puedo usarlo en el entorno de producción.

Me pregunto por qué tres enfoques mencionados anteriormente no funcionó cuando he mencionado los mismos valores en el server.xmlde app2los valores del servidor y en el mismo almacén de confianza por el ajuste

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

en el app1programa

Para obtener más información, así es como estoy haciendo la conexión:

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());

Debe agregar el certificado para App2 al archivo del almacén de confianza de la JVM utilizada ubicada en %JAVA_HOME%\lib\security\cacerts.

Primero puede verificar si su certificado ya está en el almacén de confianza ejecutando el siguiente comando: keytool -list -keystore "%JAVA_HOME%/jre/lib/security/cacerts"(no necesita proporcionar una contraseña)

Si falta su certificado, puede obtenerlo descargándolo con su navegador y agregarlo al almacén de confianza con el siguiente comando:

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

Después de la importación, puede ejecutar el primer comando nuevamente para verificar si se agregó su certificado.

La información de Sun / Oracle se puede encontrar aquí .

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: error en la construcción de la ruta PKIX: sun.security.provider.certpath.SunCertPathBuilderException: no se puede encontrar la ruta de certificación válida para el objetivo solicitado

• Cuando recibí el error, intenté buscar en Google el significado de la expresión y descubrí que este problema se produce cuando un servidor cambia su certificado SSL HTTPS y nuestra versión anterior de Java no reconoce la autoridad de certificación raíz (CA) .

• Si puede acceder a la URL HTTPS en su navegador, entonces es posible actualizar Java para reconocer la CA raíz.

• En su navegador, vaya a la URL HTTPS a la que Java no pudo acceder. Haga clic en la cadena de certificados HTTPS (hay un icono de candado en Internet Explorer), haga clic en el candado para ver el certificado.

• Vaya a "Detalles" del certificado y "Copiar a archivo". Copiarlo en base 64 (.cer) formato. Se guardará en su escritorio.

• Instale el certificado ignorando todas las alertas.

• Así es como reuní la información del certificado de la URL a la que intentaba acceder.

Ahora tenía que hacer mi versión de Java para conocer el certificado para que no se negara a reconocer la URL. A este respecto, debo mencionar que busqué en Google que la información del certificado raíz permanezca por defecto en la ubicación de seguridad de JDK \ jre \ lib \ , y la contraseña predeterminada para acceder es: changeit.

Para ver la información de cacerts, los siguientes son los procedimientos a seguir:

• Haga clic en el botón Inicio -> Ejecutar

• Escriba cmd. Se abre el símbolo del sistema (es posible que deba abrirlo como administrador).

• Ve a tu Java/jreX/bindirectorio

• Escriba lo siguiente

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

Da la lista de los certificados actuales contenidos en el almacén de claves. Se parece a esto:

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

Introduzca la contraseña del almacén de claves: changeit

Tipo de almacén de claves: jks

Proveedor de almacén de claves: SUN

Su almacén de claves contiene 44 entradas

verisignclass3g2ca, 26 de marzo de 2004, TrustedCertEntry,

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

entrustclientca, 9 de enero de 2003, TrustedCertEntry,

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

thawtepersonalbasicca, 13 de febrero de 1999, TrustedCertEntry,

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

addtrustclass1ca, 1 de mayo de 2006, TrustedCertEntry,

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

verisignclass2g3ca, 26 de marzo de 2004, TrustedCertEntry,

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

• Ahora tenía que incluir el certificado previamente instalado en los cacerts.

• Para esto, el siguiente es el procedimiento:

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

Si está utilizando Java 7:

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

• Luego agregará la información del certificado al archivo cacert.

¡Es la solución que encontré para la excepción mencionada anteriormente!

Cómo trabajarlo en Tomcat 7

Quería admitir un certificado autofirmado en una aplicación Tomcat, pero el siguiente fragmento no funcionó

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);
    }
}

Esto es lo que resolvió mi problema:

1) Descargar el .crtarchivo

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

• reemplazar <your domain>con su dominio (por ejemplo jossef.com)

2) Aplicar el .crtarchivo en el cacertsalmacén de certificados de Java

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

• reemplazar <your domain>con su dominio (por ejemplo jossef.com)
• reemplace <JAVA HOME>con su directorio de inicio de Java

3) piratearlo

Aunque instalé mi certificado en Javalos almacenes de certificados predeterminados, Tomcat lo ignora (parece que no está configurado para usar los almacenes de certificados predeterminados de Java).

Para hackear esto, agrega lo siguiente en algún lugar de tu código:

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

// ...

En mi caso, el problema era que el servidor web solo enviaba el certificado y la CA intermedia, no la CA raíz. Agregar esta opción JVM resolvió el problema:-Dcom.sun.security.enableAIAcaIssuers=true

El soporte para el método de acceso de caIssuers de la extensión de Acceso a la Información de la Autoridad está disponible. Está deshabilitado de forma predeterminada por compatibilidad y se puede habilitar configurando la propiedad del sistema com.sun.security.enableAIAcaIssuersen el valor verdadero.

Si se establece en verdadero, la implementación PKIX de Sun de CertPathBuilder utiliza la información en la extensión AIA de un certificado (además de CertStores que se especifican) para encontrar el certificado CA emisor, siempre que sea un URI de tipo ldap, http o ftp.

Fuente

Otra razón podría ser una versión desactualizada de JDK. Estaba usando jdk versión 1.8.0_60, simplemente actualizar a la última versión solucionó el problema del certificado.

Mi archivo de cacerts estaba totalmente vacío. Resolví esto copiando el archivo cacerts de mi máquina Windows (que usa Oracle Java 7) y lo scp'd a mi caja de Linux (OpenJDK).

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

y luego en la máquina de Linux

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

Ha funcionado muy bien hasta ahora.

Para mí, este error también apareció al intentar conectarse a un proceso detrás de un proxy inverso NGINX que manejaba el SSL.

Resultó que el problema era un certificado sin toda la cadena de certificados concatenados. Cuando agregué certificados intermedios, el problema se resolvió.

Espero que esto ayude.

Usando Tomcat 7 bajo Linux, esto hizo el truco.

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

En Linux, $JAVA_HOMEno siempre se configura, pero generalmente /etc/alternatives/jreapunta a$JAVA_HOME/jre

El siguiente código funciona para mí:

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());

Estaba usando jdk1.8.0_171cuando me enfrenté al mismo problema. Intenté las 2 mejores soluciones aquí (agregando un certificado usando keytool y otra solución que tiene un truco) pero no funcionaron para mí.

Actualicé mi JDK 1.8.0_181y funcionó de maravilla.

escribí un pequeño script estúpido de cmd (línea de comando) win32 (WinXP 32bit testet) que busca todas las versiones de java en los archivos de programa y les agrega un certificado. La contraseña debe ser el "changeit" predeterminado o cámbielo usted mismo en el 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 MacOS X a continuación, el comando exacto funcionó para mí, donde tuve que probar con doble bombo en la opción 'importcert' que funcionó:

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 mí no funcionó la solución reconocida de esta publicación: https://stackoverflow.com/a/9619478/4507034 .

En cambio, logré resolver el problema importando la certificación a las certificaciones confiables de mi máquina.

Pasos:

1. Vaya a la URL (p. Ej. https://localhost:8443/yourpath) Donde la certificación no funciona.
2. Exporte la certificación como se describe en la publicación mencionada.
3. En su máquina de Windows abierta: Manage computer certificates
4. Ir a Trusted Root Certification Authorities->Certificates
5. Importa aquí tu your_certification_name.cerarchivo.

Para que Tomcat se ejecute en el servidor Ubuntu, para averiguar qué Java se está utilizando, use el comando "ps -ef | grep tomcat":

Muestra:

/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

Luego, podemos ingresar a: cd /usr/local/java/jdk1.7.0_15/jre/lib/security

El archivo cacerts predeterminado se encuentra aquí. Inserte el certificado no confiable en él.

por seguridad no debemos usar certificados autofirmados en nuestra implementación. Sin embargo, cuando se trata de desarrollo, a menudo tenemos que usar entornos de prueba que obtuvieron certificados autofirmados. Traté de solucionar este problema mediante programación en mi código y fallo. Sin embargo, al agregar el certificado al jre trust-store se solucionó mi problema. Por favor encuentre los pasos a continuación,

1. Descargue el certificado del sitio,

   • Usando Chrome
   • Usando Firefox

2. Copie el certificado (ej: cert_file.cer) en el directorio $ JAVA_HOME \ Jre \ Lib \ Security

3. Abra CMD en Administrador y cambie el directorio a $ JAVA_HOME \ Jre \ Lib \ Security

4. Importe el certificado a un almacén de confianza con el siguiente comando,

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

Si recibió un error diciendo que keytool no es reconocible, consulte esto.

Escriba yes como abajo

Confíe en este certificado: [Sí]

5. Ahora intente ejecutar su código o acceder a la URL mediante programación usando java.

Actualizar

Si su servidor de aplicaciones es jboss, intente agregar debajo de la propiedad del sistema

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

¡Espero que esto ayude!

SOLUCIÓN DESPLEGABLE (Alpine Linux)

Para poder solucionar este problema en nuestros entornos de aplicación, hemos preparado los comandos de terminal de Linux de la siguiente manera:

cd ~

Generará un archivo cert en el directorio de inicio.

apk add openssl

Este comando instala openssl en alpine Linux. Puede encontrar los comandos adecuados para otras distribuciones de Linux.

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

Generado el archivo cert necesario.

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

Aplica el archivo generado al JRE con el programa 'keytool'.

Nota: Reemplace su DNS con<host-dns-ssl-belongs>

Nota 2 : tenga en cuenta que -nopromptno se solicitará el mensaje de verificación (sí / no) y el -storepass changeitparámetro deshabilitará la solicitud de contraseña y proporcionará la contraseña necesaria (el valor predeterminado es 'changeit'). Estas dos propiedades le permitirán usar esos scripts en los entornos de su aplicación, como crear una imagen de Docker.

Nota3 Si está implementando su aplicación a través de Docker, puede generar el archivo secreto una vez y ponerlo en los archivos de proyecto de su aplicación. No necesitará generarlo una y otra vez.

Tengo este problema también.

Intenté casi todo agregando el certificado SSL a .keystore, pero no funcionaba con Java1_6_x. Para mí, ayudó si comenzamos a usar una versión más nueva de Java, Java1_8_x como JVM.

Estaba teniendo este problema con Android Studio cuando estoy detrás de un proxy. Estaba usando Crashlytics que intenta cargar el archivo de mapeo durante una compilación.

Agregué el certificado proxy faltante al almacén de confianza ubicado en /Users/[username]/Documents/Android Studio.app/Contents/jre/jdk/Contents/Home/jre/lib/security/cacerts

con el siguiente comando: keytool -import -trustcacerts -keystore cacerts -storepass [password] -noprompt -alias [alias] -file [my_certificate_location]

por ejemplo con la contraseña predeterminada del almacén de confianza keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias myproxycert -file /Users/myname/Downloads/MyProxy.crt

Solo un pequeño truco. Actualice la URL en el archivo "hudson.model.UpdateCenter.xml" de https a http

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

Quiero intervenir ya que tengo un entorno QEMU donde tengo que descargar archivos en Java. Resulta que /etc/ssl/certs/java/cacertsen QEMU tiene problemas porque no coincide /etc/ssl/certs/java/cacertscon el entorno del host. El entorno de host está detrás de un proxy de la empresa, por lo que java cacerts es una versión personalizada.

Si está utilizando un entorno QEMU, asegúrese de que el sistema host pueda acceder primero a los archivos. Por ejemplo puedes intentar este script en su máquina host primero para ver. Si el script se ejecuta bien en la máquina host pero no en QEMU, entonces está teniendo el mismo problema que yo.

Para resolver este problema, tuve que hacer una copia de seguridad del archivo original en QEMU, copiar el archivo en el entorno host a la cárcel chroot de QEMU, y luego Java podría descargar archivos normalmente en QEMU.

Una mejor solución sería montarlo /etcen el entorno QEMU; Sin embargo, no estoy seguro de si otros archivos se verán afectados en este proceso. Así que decidí usar esta solución fea pero fácil.

Este parece un lugar tan bueno como cualquier otro para documentar otra posible razón para el infame mensaje de error PKIX. Después de pasar demasiado tiempo mirando el contenido del almacén de claves y del almacén de confianza y varias configuraciones de instalación de Java, me di cuenta de que mi problema se había reducido a ... un error tipográfico.

El error tipográfico significaba que también estaba usando el almacén de claves como el almacén de confianza. Como la CA raíz de mi empresa no se definió como un certificado independiente en el almacén de claves, sino solo como parte de una cadena de certificados, y no se definió en ningún otro lugar (es decir, cacerts) seguí recibiendo el error PKIX.

Después de un lanzamiento fallido (esta es la configuración de prod, estuvo bien en otro lugar) y dos días de rascarse la cabeza finalmente vi el error tipográfico, y ahora todo está bien.

Espero que esto ayude a alguien.

agregue esto a su 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) {
       }