Tengo problemas para establecer la ruta del archivo cacerts al TrustStore en el entorno Linux, en Windows se ejecuta sin problemas.

Es un proyecto Spring, el archivo cacerts está dentro de la carpeta de recursos, informo la ruta cacerts al javax.net.ssl.trustStore por código y creo el .war archivo con el comando mvn clean package y en linux, al ejecutar el .war, se produce un error al intentar conectar con el servidor AD Ldap, creo que el problema son los cacerts que no se encontraron.

Mi código para informar a las cacerts:

Path keystore = null;
try {
    keystore = Files.createTempFile(null, null);

    InputStream stream = getClass().getResourceAsStream("/cacerts");

    Files.copy(stream, keystore, StandardCopyOption.REPLACE_EXISTING);

} catch (IOException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}

System.out.println(keystore.toString()); // print path 
System.setProperty("javax.net.ssl.trustStore", keystore.toString());

System.out.println (keystore.toString ()) muestra la ruta del archivo en / tmp y cuando se verifica con ls -l el archivo aparece en la lista, ¿es algún problema con el entorno Linux o es una pregunta de código que de otra manera debería resolverse?

Editado: El error que aparece en el servidor linux:

org.springframework.ldap.CommunicationException: 172.16.0.12:636; La excepción anidada es javax.naming.CommunicationException: 172.16.0.12:636 [La excepción raíz es javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No se encontraron nombres alternativos de sujeto que coincidan con la dirección IP 172.16.0.12]

0
user2831852 16 oct. 2018 a las 17:59

2 respuestas

La mejor respuesta

Creo que podría ser un problema de código.

Algunas de las propiedades de la JVM las utiliza el código que se activa mediante la inicialización estática. En este caso, la propiedad javax.net.ssl.trustStore se usa la primera vez que algo intenta acceder al almacén de claves de confianza predeterminado o al conjunto predeterminado de certificados X509 de confianza. No está claro cuándo sucede esto.

Por lo tanto, existe una gran posibilidad de que su llamada a System.setProperty se realice demasiado tarde; es decir, después de su uso.

Intente configurar la propiedad usando una opción de línea de comando -Djavax.net.ssl.trustStore=... y vea si funciona.


ACTUALIZACIÓN

Probé con -Djavax.net.ssl.trustStore, no funcionó bien porque funcionó "solo cuando quería", 10 intentos uno funcionó, aproximadamente! ¿Incluso que el uso de -Djavax.net.ssl.trustStore puede retrasar la aplicación de cacerts? En la forma en que se ejecuta este código, el método es un @Bean (name = "contextSource") dentro de una clase @Configuration. ¿Cómo puedo hacer para correr en el momento adecuado?

Al menos esto demuestra que si usa -D, la propiedad se configura con suficiente anticipación para estar disponible. ¡Esto prueba que el mecanismo no está roto!

El problema ahora será que su TrustStore archivo personalizado se está utilizando antes de que la aplicación haya tenido la oportunidad de crearlo. (Podrías probar esto ...)

1

  • Agregue un paso de implementación separado para extraer su TrustStore personalizado a un archivo en el sistema de archivos antes de iniciar el contenedor web .

  • Alternativamente, cambie la aplicación web o el contenedor web para que no dependa del mecanismo TrustStore predeterminado.

Para responder a su pregunta de seguimiento: hasta donde yo sé, no la hay. El código de seguridad de Java no está diseñado para permitir que se retrase la creación de instancias del TrustStore predeterminado ni para permitir que se modifique. ¡Mira el código fuente!


1 - Incluso si pudiera establecer la propiedad antes de que el contenedor web se inicialice e intente utilizar TrustStore, primero debe crear TrustStore a partir de un recurso de aplicación web. El cargador de clases para ese recurso lo crea webcontainer, durante o después de la inicialización del webcontainer. Lo más probable es que sea demasiado complicado lograr que los pasos sucedan de manera confiable en el orden en que los necesita.

0
Stephen C 17 oct. 2018 a las 00:32

Sobre el problema con la IP, pude resolverlo agregando el parámetro en el momento de ejecutar el archivo .war.

-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true
0
user2831852 17 oct. 2018 a las 15:04