Let's Encrypt, cortafuegos y Route 53

Let's Encrypt, la autoridad de certificación gratuita y automatizada, está revolucionando la forma de obtener y gestionar certificados SSL/TLS, pasando de los métodos tradicionales, caros y manuales, a un proceso elegante y sin costes.

Este artículo explica cómo instalar y renovar automáticamente un certificado LE en un servidor basado en RHEL utilizando la validación DNS-01 contra registros TXT en Route 53 de Amazon.

¿Cuál es el problema?

Si busca instrucciones de instalación en Google, encontrará muchos artículos que explican cómo instalar y renovar automáticamente un certificado LE utilizando el cliente Acme de Certbot. Por defecto, Certbot intentará realizar retos de validación contra el servidor al que resuelve la dirección DNS del (sub)dominio. Este método funciona muy bien si los servidores están expuestos a Internet, sin embargo, si los servidores están bloqueados detrás de un Firewall, el desafío siempre fallará.

La reacción natural, al menos para mí, fue empezar a buscar documentación en el sitio web de Let's Encrypt sobre su rango de IP para poder incluirlo en la lista blanca de nuestros cortafuegos. Sin embargo, rápidamente encontré mensajes en los foros de LE de los ingenieros de LE/Certbot en los que afirmaban que no querían anunciar direcciones específicas por razones de seguridad y que las direcciones utilizadas actualmente están sujetas a cambios.

La solución...

Afortunadamente, hay herramientas disponibles que nos ayudan a validar los certificados LE sin que el desafío tenga lugar en el servidor al que resuelve la dirección DNS del certificado que está generando.

En este ejemplo voy a utilizar una combinación de shell script Acme cliente Deshidratado y el Ruby basado en Ruta 53 DNS-01 Hook

Paso 1: Exporta tus credenciales de AWS para permitir que los scripts generen un registro TXT en Route 53. (Asegúrese de añadirlas al perfil bash de sus servidores para garantizar que los detalles persisten).

export AWS_REGION="la región va aquí"
export AWS_ACCESS_KEY_ID="clave_de_acceso_va_aquí"
export AWS_SECRET_ACCESS_KEY="clave_de_acceso_secreta_va_aquí"

Paso 2: Crear un directorio deshidratado.

mkdir /etc/deshidratado

Paso 3: Descargue el archivo de configuración por defecto.

cd /etc/deshidratado && curl -O 
https://raw.githubusercontent.com/lukas2511/dehydrated/master/docs/examples/config

Paso 4: Clone the Dehydrated Repo

clonar git 
https://github.com/lukas2511/dehydrated.git

Paso 5: Clonar el hook Ruby de Route 53

cd deshidratado && rizo -O
https://gist.githubusercontent.com/joshgarnett/02920846fea35f738d3370fd991bb0e0/raw/5412ee600278acf843832cd918455b8e6d50ba5c/lets-encrypt-route53.rb

Paso 6: Asegúrese de que el hook ruby es ejecutable

chmod +x lets-encrypt-route53.rb

Paso 7: Instalar la gema AWS-SDK

gem install aws-sdk

Paso 8: Registrarse y aceptar las condiciones

./deshidratado --register --accept-terms

Paso 9: Iniciar la generación del certificado (Sustituya ejemplo.com por su propio dominio)

./deshidratado --cron --dominio ejemplo.com --hook ./lets-encrypt-route53.rb --challenge dns-01

Paso 10: Añada el mismo comando a una tarea cron/systemd. Es posible que tu servidor web necesite recargar su configuración cuando se cree un nuevo certificado, así que no olvides añadirlo a tu tarea programada.

Por ejemplo en nginx...

cd /etc/dehydrated/dehydrated && ./dehydrated --cron --domain example.com --hook ./lets-encrypt-route53.rb --challenge dns-01 && service nginx reload

Y ya está. Ahora sólo tienes que configurar tu servidor web para que utilice el certificado/clave generados y se acabaron tus días de renovar y pagar certificados manualmente.

¡Ta mejor!