Let’s Encrypt es una Autoridad de Certificación que si bien existe desde 2014, se lanzó oficialmente (dejando su estado Beta) el 12 de abril de 2016. Provee certificados X.509 gratuitos para encriptación TLS (Transport Layer Security) a través de un proceso automatizado y diseñado para eliminar el, hasta ahora engorroso proceso manual de creación, validación, firmado, instalación y renovación de certificados para asegurar sitios web.
Todo este proceso automatizado se lleva a cabo a través de una herramienta que en un inicio se llamó igualmente letsencrypt y/o letsencrypt-auto que no eran más que scripts Bash que llevaban a cabo las tareas necesarias. Para mediados de año se cambió el Bash por Python, se le renombró a certbot y se puso a disposición a través de paquetería oficial para distintas distribuciones Linux, entre ellas: CentOS (RHEL), Fedora, Debian y Ubuntu.
Instalar Certbot:
En el caso específico de CentOS, sólo está disponible en RPM para CentOS 7, mientras que para Fedora está disponible para las versiones 23 y 24 que son las actualmente vivas. Para cualquier entorno en el que no se disponga del RPM, se puede usar el script descargado directo del sitio oficial de Certbot donde se puede encontrar instrucciones muy detalladas para cada caso. El proceso por RPM es simple, en CentOS 7 hay que agregar primero el repo de Epel antes de instalar:
$ sudo yum install epel-release $ sudo yum install certbot
En el caso de Fedora basta con mandar a instalar:
$ sudo dnf install certbot
En cualquier ambiente, la primera ejecución tardará un tiempo porque primero busca instalar los paquetes adicionales necesarios (vía yum o dnf según sea el caso) y además se actualiza automáticamente el script de certbot propiamente, si es que se determina necesario.
Primero lo primero:
Si bien las instrucciones referidas arriba sobre la instalación en el sitio oficial de Certbot, contienen la documentación básica del uso de la herramienta, incluyendo el proceso de generación del certificado, pretendo aclarar un poco el panorama pues a mí mismo se me hizo un poco confuso a momentos.
Certbot tiene dos (que yo denomino) modos principales de operación:
- Automático. Es el modo por defecto y en el cual, certbot realiza todas las operaciones prácticamente sin intervención del operador, es digamos más fácil, pero si algo falla es más complejo determinar qué. Si eres principiante o un usuario final, esta es la opción recomendada.
- Manual. En este modo, certbot trabaja con intervención directa del operador y se requiere que éste tenga un poquito más de noción, especialmente sobre gestionar los contenidos del sitio web que se desea asegurar.
En cualquier modo, lo primero es realizar la autenticación con el ACME CA. Lo que esto significa es que el sistema necesita validar que el sitio web que responde al nombre de dominio que deseamos asegurar está efectivamente bajo nuestro control. Así se evita que alguien pueda generar un certificado de un dominio que no administra.
El modo automático:
Especialmente en este modo, Certbot trabaja con lo que se denominan plugins y en función de ellos, el procedimiento varía. Existen plugins para algunos de los servidores web más populares, estos plugins hacen todo, desde la autenticación y generación hasta la instalación de los certificados. Por ciertas razones, que no vienen al caso discutir, estos plugins para servidores web específicos (Apache, Nginx, etc.) no están disponibles siempre y en todos los entornos, los que sí son omnipresentes son:
- webroot. Con este plugin, se requiere de un servidor web preexistente y funcional en el equipo y proporcionale al Certbot los detalles del webroot o document root del sitio que deseamos asegurar, así como el nombre del dominio o dominios que se desea incluir en el certificado y luego el plugin hace su magia para autenticar y validar así la solicitud.
- standalone. Con este plugin, se levanta un servicio web atendiendo por el puerto 80. Este servicio web es parte del propio Certbot y no requiere ningún tipo de intervención por parte del operador. Mientras el comando esté corriendo, el servidor estará activo y proporcionará los medios para autenticar y validar así la solicitud. Si hay un servidor web activo en el equipo, éste deberá detenerse antes de ejecutar la solicitud.
En ambos casos el comando debe ser ejecutado en el mismo equipo que contiene el servidor/sitio web que responde al nombre de dominio que se desea asegurar.
El modo manual:
Es el que a mí más me agrada, porque me resulta más flexible y principalmente porque me permite correr el comando en mi propio equipo y no en el servidor web en sí. Al escoger esta forma, se le proporciona elementalmente sólo el nombre del dominio o dominios que se desea incluir en el certificado y certbot provee con un con nombre y contenido aleatorios de un archivo que se debe poner en el servidor web, luego de lo cual se realiza la autenticación y validación de la solicitud.
En todos los escenarios, la validación se hace igual: a través de que el CA busca abrir vía web ese archivo específico y validar el contenido del mismo. La diferencia está en que el modo automático crea y coloca el archivo de forma transparente y el modo manual requiere de que el operador ponga el archivo en el lugar adecuado. Un ejemplo de este archivo podría ser:
http://paulbernal.com/.well-known/acme-challenge/HVm-mbVMrg7uK1xr_EhrjrFhyCR4fu7BTv7Kg9NIXL
Entonces lo que se requiere es hacer lo necesario para que dicha URL sea visible vía web.
Crear un Certificado:
La forma más simple y genérica de ejecución es:
# certbot certonly
El comando lanza el asistente de generación en el modo automático (que es el por defecto) y es muy simple de usar pues simplemente hay que irle proporcionando la información que va solicitando:
Los archivos del certificado se generarán y colocarán apropiadamente de acuerdo al plugin seleccionado, pero siempre se refieren al final, de tal forma que se pueda saber exactamente dónde están.
Como lo dije anteriormente, mi preferencia es la de hacerlo en modo manual, para lo cual bastaría con agregarle la opción --manual al comando:
# certbot certonly --manual
En este caso el asistente se pasa directo a la pregunta del nombre de dominio o dominios que deseo incluir en la solicitud:
Al igual que en el caso anterior, hay que irle proporcionando la información que va solicitando el asistente, la diferencia es que en este modo, el asistente nos indicará el nombre del archivo y su contenido, que hay que manualmente poner en el servidor web para que sea accesado y validado por parte del servicio de autenticación.
Es importante que no se interrumpa la ejecución del comando (asistente) mientras se realiza el proceso de colocación de archivos y respectiva validación, pues el nombre que se genera sólo es válido para esa corrida específica, si se detiene y relanza, el nombre de archivo y contenido se cambiarán completamente.
También está la opción de pasarle todos los detalles directo en el comando, por ejemplo:
# certbot certonly --manual -d paulbernal.com -d www.paulbernal.com
Como se puede apreciar, no sólo le indiqué un nombre del dominio, sino que le anexé uno más, con lo cual, estoy solicitando que el certificado incluya a los dos dominios y la gente pueda abrir mi sitio por HTTPS tanto con o sin el www y en cualquier caso se asegure la comunicación.
Una vez que se dispone de los archivos del certificado, quedará realizar la configuración apropiada de acuerdo al servidor web que usemos. Los archivos (al menos en modo manual) son generados en un directorio dentro de /etc/letsencrypt/archive y se crean enlaces simbólicos a ellos en /etc/letsencrypt/live/, en ambos lugares se almacenan dentro de una carpeta con el nombre del dominio principal del certificado, en mi caso: /etc/letsencrypt/(archive|live)/paulbernal.com.
La razón de los enlaces simbólicos es que la primera vez que se generan, los archivos llevan nombres como: cert1.pem, chain1.pem, fullchain1.pem y privkey1.pem. Cuando se renueven los certificados, en realidad se crean nuevos con los mismos nombres pero con un 2 en lugar del 1 y así sucesivamente. Certbot actualiza apropiadamente los enlaces simbólicos que en su lugar siempre llevan los nombres: cert.pem, chain.pem, fullchain.pem y privkey.pem entonces es mejor referir éstos últimos nombres (los enlaces simbólicos) en la configuración del servidor web, pues siempre apuntarán al último o más reciente certificado.
Renovar un Certificado:
El modelo de certificación de Let’s Encrypt otorga los certificados con una validez de 90 días, por lo que el proceso de renovación es vital y constante. Antes de seguir, es interesante notar que si se generan certificados para diferentes dominios en el mismo equipo, todos ellos se almacenan en el mismo esquema que se describió arriba, es decir dentro de /etc/letsencrypt y ahí dentro hay un directorio llamado renewal que contiene los archivos de configuración de cada dominio generado y son los archivos que se usan para el momento de la renovación. Entonces el comando de renovación de certificados:
# certbot renew
Intenta renovar automáticamente todos los certificados que están dentro del período de expiración (a partir de los 60 días), por lo que si se desea renovar un certificado específico, basta pasarle el nombre del dominio en cuestión:
# certbot renew -d paulbernal.com
Enseguida salta a la vista que rápidamente se puede convertir en una carga el que tenga que preocuparme de renovar mis certificados cada poco tiempo, peor aún si digamos tengo más de uno y no todos se generaron/expiran en el mismo mes. Por eso se ha pensado en que este comando de renovación sea ejecutable por medio de Cron o Systemd, con lo cual se podrá programar la tarea para ejecutarse al menos una vez a la semana y despreocuparse del tema. Pero antes de agregar el comando a una tarea programada, se sugiere probar el proceso de renovación con:
# certbot renew --dry-run
Con lo cual se realiza el proceso como si de verdad se estuviera solicitando renovar, sólo que en realidad no se generan los nuevos certificados. Si todo va bien, se puede programar la tarea con un comando similar a este cron job:
05 05 * * 05 certbot renew --quiet
Si la configuración de el/los sitio/s web en cuestión están referenciando los enlaces simbólicos en /etc/letsencrypt/live/... no hace falta tocar nada más.
Definitivamente Let’s Encrypt ha revolucionado y masificado el aseguramiento de la web, aunque hay que tener claro que este es un entorno de uso, digamos civil. No se puede pensar en usar un certificado de estos para ningún sitio que maneje información realmente sensible, no porque sea menos seguro, sino porque obviamente no se incluye ningún tipo de seguro de indemnización o garantía sobre el mismo. Parafraseando el slogan de una tarjeta de crédito: Para todo lo demás está Let’s Encrypt 😉.
