Tengo un servidor web Apache frente a un servidor web Tomcat 8 que ejecuta mi sitio web y estoy cambiando el dominio de nivel superior de my.website.ie a my.website.com. Tengo un código que se ejecuta en respuesta a una solicitud en particular que genera un PDF. Ese código obtiene una imagen (usando una URL) que se entrega desde el mismo servidor web, p. Ej.

Image.getInstance(new URL("https://my.website.com/img/myimage.png"))

Además del cambio de dominio, también cambiaré mi proveedor de certificado SSL a LetsEncrypt (certificados SSL gratuitos). Mi sitio web de desarrollo en el nuevo dominio .com se está ejecutando y el certificado es válido y no caduca durante varios meses.

Tengo otro servidor de desarrollo que se ejecuta en una máquina separada que todavía usa el dominio .ie. La base de código de Tomcat que se ejecuta en ambos servidores es idéntica en este momento. Ambos intentan recuperar la imagen en la URL que se muestra arriba en ese fragmento de código en particular.

En el servidor .ie, la solicitud que genera el PDF funciona correctamente, sin problemas para recuperar la imagen. En el servidor .com, la solicitud falla con este error:

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 destino solicitado
...
Causado por: 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
...
Causado por: sun.security.provider.certpath.SunCertPathBuilderException: no se puede encontrar una ruta de certificación válida para el objetivo solicitado

Según tengo entendido, este error es que el certificado en la URL de destino no es confiable (por ejemplo, autofirmado), pero eso no es cierto en este caso. Además, ambos servidores acceden a la misma URL para la imagen, entonces, ¿por qué un servidor confía en el certificado y el otro no?

No he realizado ningún cambio de configuración adicional en el servidor .ie que no haya realizado en el servidor .com (con respecto a la configuración del nuevo certificado), así que ¿hay algún otro (error) configuración que no he considerado?

0
RTF 16 feb. 2018 a las 22:48

2 respuestas

La mejor respuesta

No confiable significa que el software no confía en la CA utilizada. Los certificados autofirmados nunca son de confianza.

Java tiene su propio almacén de confianza (solo en Linux, ¿el almacén de confianza del sistema se usa AFAIR?). Si el certificado de CA es más reciente que la versión de Java utilizada, puede suceder que Java no confíe en la CA. Conclusión: actualice su Java.

De acuerdo con esta respuesta de Stackoverflow, necesita al menos Java 8u101 para la compatibilidad con Let's Encrypt:

¿Java es compatible con los certificados Let's Encrypt?

3
Robert 16 feb. 2018 a las 20:02

El error dice que la cadena no conduce a un certificado raíz de confianza. Los certificados raíz de CA de confianza se almacenan en el almacén de claves raíz de Java, donde obviamente falta el certificado raíz emitido por Let's Encrypt.

Puede agregar el certificado raíz manualmente a la tienda o verificar si las versiones más recientes de Java ya contienen el certificado.

1
Lothar 16 feb. 2018 a las 20:02