configurar certificado SSL gratis centos y tomcat
un corolario entre los tantos que hay que escuche decir , "Si una cosa mala puede empeorar, empeorará".
Pues si señor me pasaran las 2, En primer lugar tenia demostración programada para un día a las 14 horas , pues bien a las 13:30 el sistema me mostró que no podía entrar al sistema porque el sistema SSL había caducado !!!.
Como decía el chavo, "Calma que no panda el cunico" , me comunique con mi proveedor de certificados , GODADDY. para verificar que había pasado, pues si mal no recordaba hacia 15 días, no solo había renovado todo mi kit de certificados y dominio que tenia con ellos, aparentemente sin problemas, digo aparentemente porque actualizó casi todo menos claro el certificado preciso que necesitaba.
Hecha las consultas de rigor aún con la calme que se debe tener con las personas del CALL CENTER, total ellos solo hacen su trabajo, todo hay que decirlo se llevan toda el agua sucia del tema, que trabajo tan duro opinó yo.
Bueno, después de ponerme varias veces a esperar, no encontraron la causa del problema pero el funcionario que me atendió me indicó que el procedería hacer el pago de forma interna si yo autorizaba, claro que lo autorice. el amablemente me indicó que listo ya había renovado el certificado.
Bueno pensé no fue tan complicado, ya lo arreglaron, llegaron las 14:00 horas y efectivamente no funcionó porque el certificado esta caducado.???
Bien después de mil excusas, disculpas , madrazos silenciosos , se pospuso la reunión de demostración para los 2 días siguientes.
Me puse entonces al frente del cañón, para saber exactamente que había sucedido, nadie me dio ninguna explicación coherente, lo único que me dijeron era que como YO había dejado caducar el certificado, lo tenía que instalar de nuevo desde cero, porque aunque figuraba como renovación en realidad habían expedido uno nuevo. haaaaa entiendo.
Alguien tiene que tener la culpa sino soy yo es el presidente, bueno a lo hecho pecho y me puse a instalar el certificado nuevo.Generé un nuevo CSR
Genere un nuevo CSR, lo envíe lo firmaron y me enviaron los archivos necesarios para volver a instalarlos en mi servidor EC2 Amazon.
Cuando trato de instalar los certificados, me dice: "error La private.key no corresponde con el certificado". ???
Bueno pensé me equivoqué, con estas carreras nada raro, ciertamente esas cosas pasan, borre todo lo que tenía el anterior certificado me cerciore que no hubiera archivos basura y de nuevo generé el CSR , de nuevo me envían el archivo de claves públicos lo instaló en AWS-EC2 y de nuevo no funciono, "error private.key no corresponde".
LLamo a GODADDY, una chica muy solicita y amable me escucha el problema que tengo, me pone a esperar varios minutos , al final me dice , lo sentimos muchos pero nosotros ya expedimos el certificado y nos dicen que está correcto,
Verifique con proveedor de hosting porque el problema es de ellos, le sugerimos que para evitar estos problemas, unifique todos los servicios en un solo proveedor.
Me parece algo coherente, cuando me devuelven entonces dinero para comprar el certificado en Amazon?.
No señor no se va a poder porque ya el generamos el certificado y el departamento técnico dice que está bien.
Bueno ante esto uno que es ignorante de estos temas, voy y me comunico con Amazon, de nuevo un CALL CENTER, muy amablemente me pregunta cual es el problema, le cuento , me indica que cargue nuevamente el certificado para revisar , y nada, el mensaje sigue igual, conclusión del funcionario, después de un examen exhaustivo, el certificado está mal, por favor solicite a su proveedor un nuevo certificado y canguelo de nuevo, "puedo ayudarlo en algo mas ...".
Conclusión Godaddy no puede hacer nada porque ya generaron el certificado y Amazon no puede hacer nada porque el certificado está mal y yo ya lleva 4 días sin poder hacer la demostración y ya lo clientes mas que recelosos.
Yo siempre he pensado que los problemas no son mas que oportunidades para nuevas alternativas, haaa no señor eso no me vuelve a pasar, como pelota de ping pong y sin soluciones.
Me puso a estudiar bien el tema para que no me salgan con excusas pendejas y busque como instalar un certificado gratuito o por lo menos manejable por el usuario, sin depender de este tipo de situaciones, me encontré el consabido certificado auto firmado que no se para que lo hacen sino sirve prácticamente para nada, para pruebas dicen pero pruebas de que? porque si necesitas algo que funcione esas pruebas no sirve de nada porque el proceso es totalmente distinto, bueno encontré mucha documentación sobre el tema pero todos mas o menos con el mismo tema, generar el CSR, mandarlo a CA , esperar el archivo con la clave publica instalar en el servidor y bla,bla,bla.
Ya me esta dando por vencido, cuando como la canción de mi cacharrito de "Roberto Carlos" , "al fondo apareció " certificados Letś encrypt , certificados totalmente gratis, auto gestionados, esa ultima palabra me enamoró a primera vista, lo de gratis en realidad para el tema no me indicaba mucho, total siempre habíamos pagado por ellos, pero auto-gestionados , si que era bien interesante, y después de leer to la información que en realidad no era mucha, pues el proceso es más que sencillo y no es mucho lo que hay que hacer fuera de 3 o 4 comando y listo.
En realidad de una simpleza y belleza increíble, si es auto gestionado porque no hay que tener certificados raros firmados por nadie y lleve y traiga, el sólito se crea un certificado y lo renueva cada 3 meses que es lo que dura la vigencia de un certificado de este estilo., solo hay que crear un crontab o cualquier sistema que tenga presente la fecha y le diga que se renueve y listo , por increíble que parezca es además gratis de verdad verdad.
El tema de certificado tuvo un ligero cambio de enfoque para mi, yo tenía el certificado sobre el balanceador de cargas de mi AWS-EC2 pero eso hacia que dependiera de la estructura de Amazon, o sea la solución estaba a medias porque aunque lo que hice funcionaba sin problemas dependía del proveedor de hosting, pero leyendo un poco mas y cambiando de óptica en mi caso, resulta que era mas práctico ( digo para mi) poner el certificado no en el operador de hosting sino en sistema de aplicaciones , llámese Apache, NGIX, o Tomcat entre lo que yo uso.
Cualquier otra instancia según aprendí como en el gestor de correos,en el FTP etc.
Bueno sucede que la gente de Letś Encrypt lo que hace es que instalan un demonio ( CERTBOT lo llaman ) que hace el trabajo de certificación eficiente y silenciosamente, o sea no necesito ni a la CA ni permisos y configuraciones raras y complicadas y ceñirme a mil condiciones del proveedor de hosting todo lo tengo yo sólito auto-gestionado, no dependo de nadie, GENIAL
La mayoría de la información importante la saque de este link, que Dios lo colme de bendiciones
https://medium.com/@mashrur123/a-step-by-step-guide-to-securing-a-tomcat-server-with-letsencrypt-ssl-certificate-65cd26290b70
Lo resumo en los siguiente pasos.
1. Lo primero es que hay que tener disponible el puerto que se va certificar usualmente el http y el https. las parejas 80 443 ( en NGIX y Apache por ejemplo) o 8080 8443 en tomcat que es el que me ocupa en este caso.
Cuando digo disponibles es en 2 sentidos
- No debe haber ningún servicio corriendo en esos puertos mientras se hace la instalación que no debe demorar mas de 10 o 15 minutos.
- Los dichos puertos deben esta abiertos tipo TCP en ambas direcciones. ( IN-OUT )
# sudo yum update
3. Actualizar el epel del sistema porque el CERTBOT esta en ese repositorio.
# sudo yum install epel-release
o para los que tenemos EC2
# sudo /usr/bin/amazon-linux-extras install epel
4. Instalamos el demonio que hace todo el trabajo grueso que carga un montón de librerías python
# sudo yum install certbot
$ sudo python3 -m venv /opt/certbot/
$ sudo /opt/certbot/bin/pip install --upgrade pip
Instalar CERBOT
$ sudo /opt/certbot/bin/pip install certbot certbothacer un lin del comando cerbot en pyton para usrlo como un comandoconvencional de consolasudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot2.Hacerlo directamente de desde las librerías de Phyton mediante, debe tener instaladoawscli. usualmente viene instaldo por defecto sino está instalar con:$ sudi yum istall awscliahora podemos usar el comando pip
# sudo certbot certonly --standalone -d www.miservidor.com -d miservidor.com
Si todo va bien le envía un pantallazo indicando varias cosas que debes tener presentes.
Your key file has been saved at:
/etc/letsencrypt/live/www.midomio.com/privkey.pem
tweaked version of this certificate in the future, simply run
certbot again. To non-interactively renew *all* of your
certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
En la linea que resalte en amarillo esta la ruta donde el CERBOT dejó las archivos de interés en este caso:
/etc/letsencrypt/live/www.midomio.com
Pero además te indica los archivos de interés para configurar tu servicio,
fullchain.pem (el equivalente al archivo .crt devuelto por la CA) es el archivo de clave pública y pivkey.pem (cuya extension mas conocida es .key) es el archivo de clave privada.
Hasta ahí es la generalidad y se aplica para todos los servicios stand-alone que ellos llaman , es decir para los cuales no tiene CERTBOT especializado, Apache y NGIX entre otros tiene sistemas especializados que hacen toda la carpintería por nosotros.
Esa carpinteril consiste esencialmente en:
- Convertir el archivo fullchain.pem en el formato que el servicio reconoce. pk12 por ejemplo
- Instalar ese nuevo archivo en el lugar indicado dependiendo del servicio
- activar el demonio de actualización "cerbot renew" del certificado en el crontab.
En mi caso tomcat se considera un stand-alone por lo tanto la carpintería la tengo que hacer y, pero en realidad no es mucho.
a) convertir el archivo fullchain.pem a un formato que tomcat reconozca que en mi caso es pk12.
# sudo yum install openssl
# sudo openssl pkcs12 -export -out /tmp/www.midominio.p12 -in /etc/letsencrypt/live/www.midominio.com.co/fullchain.pem -inkey /etc/letsencrypt/live/www.midominio.com.co/privkey.pem -name tomcat
NOTA: Verifique en la carpeta /etc/letsencrypt/live como quedaron los nombre de los archivos, en este caso están precedidos del www. pero puede no ser así.
Este comando solicita una clave cualquiera por ejemplo, miclave
que mas tarde se usa al configurar el tomcat para que use el certificado generado.
En el comando anterior:
-out es un nombre cualquiera que usted pueda reconocer luego en la instalación.
- name es cualquier nombre que le sirve al sistema para localizar la entrada de la clave publica al almacen de claves (store key) , puede dejar tomcat sin problema
-in es la ruta totalmente cualificada del archivo fullchain.pem como se indico en en mensaje de salida al crear el certificado con el certtbot.
-inkey es la ruta totalmente cualificada del archivo privkey.pem como se indica en el mensaje se salida del crear el certificado con el certbot.
Cuando ejecute este comando le va pedir una contraseña, es importante tenerla a mano porque se necesita para configurar el servicio tomcat.
b) Copie el archivo que se genero en -out , en mi caso
/tmp/www.midominio.p12 en la carpeta /conf de su ruta de tomcat.
Puede dejarla donde la genero ("/tmp") pero yo por comodidad la paso a tomcat/conf para que en caso de que toque re-instalar una copia de mi sistema todos los archivos estén a mano.
# sudo /tmp/midominio.com.pk12 /tomcat/conf
c) Configuramos el tomcat para que use ese certificado en el archivo server.xml de la carpeta /conf de su tomcat.
Puede usar nano, emacs o vim o cualquier editor texto de su preferencia.
Yo coloque en mi sistema los puertos 80 y 443 para que el tomcat este de frente al servidor de aplicaciones , en algunos casos también uso Apache y Nginx en ese caso lo dejo como están por defecto, puede hacer uso de los puertos que estime conveniente tomcat normalmente usa 8080 y 8443.
# sudo cd /etc/tomcat/conf/server.xml
Asegure el puerto de salida
<!--- <Connector port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" /> -->
Configure connector para usar un shared thread pool
<Connector executor="tomcatThreadPool"
port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Ahora SSL HTTP/1.1 Connector on port 8443
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150"
SSLEnabled="true"
scheme="https"
secure="true"
keystoreFile="conf/midominio.com.pk12"
keystorePass="miclave"
clientAuth="false" sslProtocol="TLS" /
>
Si el por alguna razón el CertBot no se renueva automáticamente mediante el crontab se puede forzar para que se actualice,
Comentarios
Publicar un comentario