Actualmente, es más sencillo contar con un certificado de seguridad, para un sitio web, todo gracias a letsencrypt, es un servicio gratuito para tener un certificado de seguridad, con el cual se puede cifrar el contenido hacia el usuario visitante, es decir, el sitio web puede visitarse a través de “https” con un certificado valido, cabe recalcar que existen diferentes tipos de certificados, dependiendo nuestra necesidad puede servir o no el uso de letsencrypt.
Para usar letsencrypt, basta con instalar en nuestra distro favorita, el comando certbot o al menos la manera de hacerlo en GNU/Linux Debian, seria la siguiente.
# apt-get -f install certbot python3-certbot-apache
Al momento de escribir este post, el comando anterior funciona para instalar el comando certbot de letsencrypt, en un servidor que utiliza Apache como servidor de páginas web, también instala un cron para la renovación automática de los certificados que tengamos.
Una vez instalado el comando certbot, podemos generar los certificados de seguridad que necesitemos, para ello, indicaremos a certbot los dominios o subdominios que necesitan un certificado de seguridad, se puede consultar la documentación si es necesario.
# certbot --apache -d dominio1.com -d dominio2.com
Con el comando anterior, certbot tomara en cuenta el plugin de Apache, para incluir la configuración adicional necesaria, agregara algunas lineas al archivo de nuestro dominio en Apache, por ejemplo, puede ser “000-default.conf” y creara un nuevo archivo llamado “000-default-le-ssl.conf”.
Como se puede observar, la instalación y configuración de certbot, es muy sencilla, con lo anterior, ya están funcionando los dominios o subdominios con un certificado de seguridad y sirviendo paginas en un protocolo seguro como lo es “https”.
Desde que comencé a utilizar certbot, para manejar los certificados de seguridad, hasta hace poco, no había experimentado ningún problema en la renovación automática de los certificados.
El problema en la renovación de los certificados, viene a raíz de un cambio en la configuración, es decir, actualmente todos los sitios web o en su mayoría, muestran todo el contenido bajo “https”, para ello, se realiza una redirección utilizando cualquier método, puede ser a través del “.htaccess”, “Cloudflare” o en la propia configuración de Apache.
Pero, al realizar una redirección de todo el contenido a “https”, rompe la renovación de los certificados de seguridad, mediante certbot, cuando certbot necesita renovar los certificados de seguridad, realiza algunas operaciones, contacta al servidor de letsencrypt, resuelve un “challenge” o “reto” y lo sirve a los servidores de letsencrypt, aquí es donde el problema surge, por esta razón, en algunas ocasiones, se necesita agregar las siguientes lineas a cada regla que tengamos en el archivo “.htaccess”, para evitar que los servidores de letsencrypt reciban una redirección, en lugar de la respuesta al “challenge”, la cual se sirve solo por “http” y no por “https”.
# letsencrypt
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/(?:\ Ballot169)?
Existe una situación muy distinta, cuando utilizamos Cloudflare, para realizar una redirección de contenido a “https”, Cloudflare integra una opción sencilla, pero lamentablemente, realiza una redirección de todo el contenido, sin manera de especificar una exclusión, como en las lineas anteriores para “.htaccess”.
También, certbot agrega una redirección de todo el contenido a “https”, mediante la configuración de Apache, si se le indica en el proceso de creación de los certificados de seguridad, hasta el momento no he utilizado esa opción, no sé si se repita este tipo de problema en ese caso.
Cuando vi este problema en un servidor, fue necesario renovar el certificado de manera manual, además, cambiar temporalmente la configuración de seguridad que se tiene en Cloudflare, lo que es un dolor de cabeza cada cierto tiempo.
Al revisar los registros o “logs” de letsencrypt, se puede ver el proceso que sigue certbot para la renovación de certificados, me llamo la atención, como se sirve la respuesta al “challenge” o “reto” pero con el plugin de Apache, en el proceso certbot modifica de manera temporal el archivo de configuración del sitio en “http”, pero no lo hace para el sitio en “https”, es decir, si nuestro contenido se redirecciona totalmente a “https” mediante Cloudflare, certbot solo prepara la respuesta para “http” y deja intacta la configuración de “https”, con lo cual, tendremos un hermoso “error 404, no autorizado“.
Para solucionar este último problema, solo fue necesario editar la configuración que utiliza certbot para la renovación, la cual se puede encontrar en el directorio “/etc/letsencrypt/renewal”, dependiendo el nombre del dominio se encontrara un archivo “.conf”.
Ejemplo.
# renew_before_expiry = 30 days
version = 0.XX.0
archive_dir = /etc/letsencrypt/archive/dominio.com
cert = /etc/letsencrypt/live/dominio.com/cert.pem
privkey = /etc/letsencrypt/live/dominio.com/privkey.pem
chain = /etc/letsencrypt/live/dominio.com/chain.pem
fullchain = /etc/letsencrypt/live/dominio.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = apache
server = https://acme-v02.api.letsencrypt.org/directory
installer = apache
account = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Se cambia el método “authenticator” de “apache” a “webroot”, “webroot” es una opción de certbot para la configuración, este método consiste en crear la respuesta del “challenge” o “reto”, utilizando el sistema de archivos, es decir, se creara un archivo o enlace al “challenge” o “reto” para ser servido a los servidores de letsencrypt, sin importar si se utiliza “http” o “https”, el archivo de configuración anterior, debe quedar de la siguiente manera.
# renew_before_expiry = 30 days
version = 0.XX.0
archive_dir = /etc/letsencrypt/archive/dominio.com
cert = /etc/letsencrypt/live/dominio.com/cert.pem
privkey = /etc/letsencrypt/live/dominio.com/privkey.pem
chain = /etc/letsencrypt/live/dominio.com/chain.pem
fullchain = /etc/letsencrypt/live/dominio.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = webroot
server = https://acme-v02.api.letsencrypt.org/directory
installer = apache
account = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[[webroot_map]]
dominio.com = /var/www/dominio.com/
Después de realizar varias pruebas y replicar este cambio de configuración con otros servidores, no he visto hasta el momento más errores en el proceso de renovación de certificados de seguridad.
Esto último, no quiere decir, que se cambie la forma en la que se generan por primera vez los certificados de seguridad, mediante certbot para Apache, el proceso debe ser el mismo, utilizando el plugin para Apache, solo que al final, es necesario realizar esta modificación.
En tuxsoul necesitamos tu apoyo con más Pizza, para seguir escribiendo.
In todays age of PS4s and XBOX ONEs plus Uber loaded PCs the graphics of this arcade are still going strong in nostalgia the fun is still there, the thrill to make those pixels survive as long as possible keeps this game alive.
A new champion enters the battle of IRC clients, but in this case Quassel IRC does more than just being a client.
