Hace algunas semanas me encontré trabajando en la migración de un producto y para finalizar la tarea tenía que probar el envío de un e-mail, que ya estaba implementado, era solo invocarlo y verificar el funcionamiento de la migración. Cuando lo intenté, me encontré con el siguiente mensaje:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty¿Y esto con qué se come?
Pues toda la literatura que pueden encontrar en internet apunta a un sola cosa: el sistema no puede acceder al repositorio de certificados, conocido en java con su nombre por defecto: «cacerts».
Un poco de historia
Para establecer una conexión segura a través de SSL/TLS es requerido confiar en el servidor y/o en el cliente. El servidor generalmente se auto identifica con un certificado digital, en cualquiera de sus formatos, por ejemplo X.509 por mencionar uno. Para saber si estos certificados son válidos o aceptados el cliente verifica la existencia del certificado en su almacén de certificados de confianza, o la existencia de la entidad emisora.
En Java los certificados más básicos requeridos vienen por defecto en un archivo llamado «cacerts» que se encuentra en la propia instalación de la JRE. Este archivo viene protegido por una clave conocida mundialmente, pero debe ser modificada por seguridad en ambientes de producción.
Entonces ¿que ocurría?
En el ambiente de desarrollo, donde estaba trabajando tenía todo por defecto. El cacerts estaba correcto y accesible, tenía los certificados requeridos. Entonces, ¿que pasaba? Toda la documentación lo decía claramente, tu programa no puede acceder al cacerts. Ya era una cuestión fé.
Llegué a leer el javadoc de Oracle, llegué a buscar el código fuente de Java para ver que estaba ocurriendo. Pero seguía con el mismo problema. Entonces decidí reconfigurar el programa y llevarlo a utilizar el cacerts que yo iba a colocar en un lugar especifico.
Eso es bastante fácil solo hay que colocar dos properties al iniciar el sistema:
#para indicar la ruta al archivo
javax.net.ssl.trustStore=/some/loc/on/server/our_truststore.jks
#para indicar el password para abrirlo
javax.net.ssl.trustStorePassword=our_passwordFácil, ¿no?
Pues seguía sin funcionar. Me dediqué entonces a buscar y revisar porque no podía acceder a mi cacerts que le estaba indicando directamente al sistema. Y perdí horas buscando en el lugar incorrecto. Claro al final parece un error tonto pero cuando pasas días trancado con el mismo problema y ninguna solución funciona ya dudas de ti mismo o de si la Matrix no te está perjudicando para esconder algún secreto importante.
Finalmente me encontré con un programa muy útil que me dio la pista correcta para resolver este enigma.
jinfo
Jinfo es un programa muy muy viejo que es un poco despreciado pero tiene una gran utilidad. Conociendo el pid del proceso java en ejecución pude obtener el valor de las properties en ese momento, justo antes de necesitarlas y bingo! No tenían los valores que yo estaba configurando.
Ni la ruta al cacerts ni el password era el que yo estaba configurando. Entonces fue claro. Había una configuración oculta que estaba modificando el valor, que tonto. Y es un error de novato, claro que en una plataforma de veinte millones de lineas de código y miles de properties de configuración se te pueden perder algunas. La encontré!
Como por arte de magia todo empezó a funcionar cuando eliminé las properties que estaban estorbando en mi ambiente.
Pensamientos
La sensación de éxito al finalizar la tarea se vio opacada por la sensación de estupidez al perder mucho tiempo buscando algo tonto. Pero luego recuerdo el mensaje de error original y me molesto!
Hubiera sido evidente y sencillo poner un mensaje: «No puedo abrir el trustStore en X ruta» o «El password para el trustStore es incorrecto».
Muchas veces los programadores olvidamos que los usuarios merecen un mensaje adecuado para entender la situación y muchas otras veces olvidamos que esos usuarios somos nosotros mismos.
Links de interés
https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty
https://www.baeldung.com/java-trustanchors-parameter-must-be-non-empty
https://www.websecurity.digicert.com/es/es/security-topics/what-is-ssl-tls-https
Muchas gracias por leer y llegar hasta el final!!
