Lidiando recientemente con las solicitudes del área de desarrollo, hubo que actualizar un certificado vencido en uno de sus maravillosos portales desarrollados en Java y servidos con Tomcat. La experiencia vivida con eso fue terrible, pues no tienen ni la más mínima idea de como hacer un sitio seguro. Solo se cercioran de descomentar los items relacionados con SSL en el archivo server.xml y colocar allí un archivo de certificados que tampoco saben como está hecho, ni por mera curiosidad relacionada a la herramienta de desarrollo que utilizan.
Por otro lado, no había documentación oficial en la organización de como se hizo el proceso, ni donde guardaron los archivos de solicitud de firma y la clave privada (CSR y Key file), mucho menos el equipo estrella de desarrollo.
Aunado a esto, el certificado firmado del dominio fue proporcionado por Godaddy, cuyos certificados no son reconocidos por Java (al menos no como lo dice la documentación de Tomcat) y de paso, el procedimiento explicado por ellos para colocarlos en servidores Tomcat NO FUNCIONA.
La raíz del problema
Las aplicaciones web desarrolladas en Java requieren un almacén de certificados para este tipo de lenguaje (Java Keystore). Este contenedor puede ser creado con Keytool, una herramienta similar a OpenSSL pero es propia de Java, bastante práctica pero con ciertas limitaciones. Con Keytool se pueden hacer:
- El contenedor de claves (JKS)
- La solicitud de firma de Certificado (archivo CSR)
El procedimiento para hacer un Keystore y la solicitud de firma es bastante simple:
1.- Crear el archivo de llaves:
keytool -genkey -alias midominio -keyalg RSA -keystore keystore.jks -keysize 2048
2.- Generar el archivo de solicitud de firma (CSR) basado en el nuevo keystore:
keytool -certreq -alias midominio -keystore keystore.jks -file midominio.csr
3.- El proceso siguiente es el que corresponde a responder las preguntas del certificado (que omitiré por mera practicidad), que al final debe confirmar afirmativamente para crear el archivo.
Ya con el archivo CSR creado, se hace la solicitud de firma ante cualquier Autoridad de Certificación (GlobalSign, Verisign, Norton, Godaddy). Una vez hecho eso, la empresa que firma le entregará el certificado firmado (CRT) junto a dos archivos: el Certificado Raíz (root) y el Certificado Intermedio, ambos necesarios, sin eso no es posible validar la autenticidad del certificado ya firmado.
4.- Importar los certificados obtenidos de manera ordenada dentro del almacén de claves (Keystore)
keytool -import -trustcacerts -alias root -file root.crt -keystore keystore.jks
keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore.jks
keytool -import -trustcacerts -alias midominio -file midominio.crt -keystore keystore.jks
(Importante: desde el proceso de creación del almacén se requiere una contraseña que no debe olvidarse, ojo)
Y voilá! Tiene un archivo keystore listo para ser usado en sus servidores web con Java.
Se verifica el contenido del almacen de certificados, y el Keytool deberá mostrar algo como esto:
keystore -list -keystore keystore.jks -storepass password
Tipo de Almacén de Claves: JKS
Proveedor de Almacén de Claves: SUNSu almacén de claves contiene 3 entradas
root, 17/02/2016, trustedCertEntry,
Huella Digital de Certificado (SHA1): 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
midominio, 20/01/2017, trustedCertEntry,
Huella Digital de Certificado (SHA1): 35:A3:AB:6A:EA:11:4F:E4:1C:8D:4C:51:F4:82:3F:4E:31:B5:97:CA
intermediate, 17/02/2016, trustedCertEntry,
Huella Digital de Certificado (SHA1): 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
Hasta ahora parece sencillo, termina configurando su servidor Tomcat agregando en el archivo de configuración server.xml lo relacionado a la conexión por HTTPS:
<Connector port=»8443″ maxThreads=»200″ scheme=»https» secure=»true» SSLEnabled=»true»
keystoreFile=»/la/ruta/al/archivo/keystore.jks»
keystorePass=»contraseñadelarchivokeystore» clientAuth=»false» sslProtocol=»TLS»/>
¿Y donde está el problema?
Todo esto funciona muy bien cuando la CA que firma los certificados es cualquiera, menos Godaddy. Mi compadre y colega @eu53 en su amplia experiencia me explica que estos certificados por Godaddy son emitidos para servidores web como Apache2 (httpd), y servidores como Tomcat les da un tratamiento como tales. No son certificados que una app web hecha en Java reconocerá de manera inmediata.
La solución consiste en convertir los certificados en un formato que sea reconocido por las apps java (desde Tomcat 6 en adelante), como PKCS12.
Para esto se requiere en el mejor de los casos:
- El certificado firmado por la Autoridad Certificadora (el archivo midominio.crt)
- El certificado Raíz de la Autoridad Certificadora (root.crt)
- El certificado Intermedio de la CA (supuestamente se requiere para Godaddy)
- El archivo de clave privada con el que se generó la solicitud de firma originalmente (archivo .key)
Pero, keytool NO genera un archivo de clave privada (archivo.key) con el que originalmente se puede generar el archivo CSR (midominio.csr). Volvemos al problema: y entonces cómo?
La Solución: hacer las cosas bien desde el principio
Mi recomendación es hacer el proceso de generación de claves con OpenSSL.
1.- Crear los certificados de clave privada y requerimiento de firma:
openssl req -new -newkey rsa:2048 -nodes -out midominio.csr -keyout midominio.ke
(se responden las preguntas de la organización de origen, y se coloca la contraseña de la clave privada, que no debe olvidarse)
El resultado del proceso son los archivos midominio.key y midominio.csr
2.- Ya con el archivo CSR creado, se hace la solicitud de firma ante cualquier Autoridad de Certificación asi como se explicara en este documento. Para el caso en particular, Godaddy.
Una vez hecho eso, la empresa que firma le entregará el certificado firmado (CRT) junto a dos archivos: el Certificado Raíz (root) y el Certificado Intermedio empaquetados en un archivo ZIP que se descarga desde el portal de Godaddy.
3.- Crear el almacen de certificados (Keystore) con Keytool:
keytool -genkey -alias midominio -keyalg RSA -keystore tomcat.jks
(en este paso, responda las preguntas con los mismos datos proporcionados al ejecutar el paso 1 con openssl)
4.- Exportar el certificado firmado y la clave privada al formato PKCS12
openssl pkcs12 -export -in midominio.crt -inkey midominio.key -out midominio.p12 -name midominio -CAfile ca.crt -caname root
5.- Finalmente, importar el archivo PKCS12 en el almacen de certificados usando Keytool:
keytool -importkeystore -deststorepass <elpassworddelarchivoJKS> -destkeypass <elpassworddelarchivoKey> -destkeystore tomcat.jks -srckeystore midominio.p12 -srcstoretype PKCS12 -srcstorepass <elpassworddelarchivoJKS> -alias midominio
(para propósitos prácticos, use el mismo password utilizado en el archivo key para su keystore)
El contenido del almacen de certificados se verá de esta forma:
Tipo de Almacén de Claves: JKS
Proveedor de Almacén de Claves: SUNSu almacén de claves contiene 1 entrada
midominio, 17/02/2016, PrivateKeyEntry,
Huella Digital de Certificado (SHA1): B3:6B:2B:D6:00:43:4E:B4:BF:03:53:F2:DE:FE:FE:2C:F2:F9:5D:53
Ahora si, el certificado se encuentra listo para ser usado en el servidor Tomcat, para es se modifica el archivo server.xml:
<Connector port=»8443″ maxThreads=»200″ scheme=»https» secure=»true» SSLEnabled=»true» keystoreFile=»/la/ruta/del/archivo/tomcat.jks»
keystorePass=»elpassworddelarchivoJKS» clientAuth=»false» sslProtocol=»TLS»/>
Para mantener un orden debido en las configuraciones de un servidor, ubique el archivo de certificados en un lugar especifico. Se puede crear un directorio adicional en /usr/local para guardar los certificados agregados.
Un problema (des)conocido
El equipo de desarrollo no está feliz: a pesar que ya el portal tiene un certificado que funciona en su sitio, en la ejecución de tan maravillosa obra de arte desplegado en el servidor muestra un error luego de autenticar y hacer llamadas a unos subprogramas dentro del mismo servidor:
2017-01-26 16:56:06,274 [ CommonUtils.java:http-bio-443-exec-3:getResponseFromServer:327] – sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Alegato del desarrollador: el certificado no sirve.
Luego de consultar foros y nuevamente acudir a la sabia experiencia de mi compadre @eu53 en materia de Tomcat, me explica lo siguiente:
«Básicamente el problema que tienes es confianza con el certificado raíz que firmó tu certificado público, posiblemente sea que el certificado de la entidad verificadora haya sido recientemente actualizado y no esté esa versión incluida en el cacert de tu version de Java. La solución es agregar el certificado al cacert y asi cualquier app java o servidor que levantes usando ese JRE tenga ya el certificado entre su truststore, pero de todas todas el certificado no esta malo, simplemente hay que actualizar el listado de certificados».
Y en efecto, lo recomendado es actualizar el certificado raíz de la CA con que se firmó el certificado del sitio en el almacén de claves de Java, en este caso de la versión que estará usando Tomcat. Para eso entonces nuevamente se hace uso de keytool:
keytool -importcert -file gd_bundle-g2-g1.crt -alias godaddy -keystore $JAVA_HOME/jre/lib/security/cacerts
(el password del almacén es «changeit»)
Problema resuelto.
Todo lo mencionado aquí funciona con las versiones de Tomcat 6, 7 y 8.
Escritos desde la Roca 