Ansible Certbot: Automatiza HTTPS con Let’s Encrypt 2026

El cifrado HTTPS ya no es opcional: buscadores, navegadores y normativas lo exigen. Ansible Certbot te permite obtener y renovar certificados Let’s Encrypt de forma repetible, auditable y sin intervención manual en cada servidor. En esta guía verás cómo encajar Certbot en tu flujo de automatización, qué decisiones tomar (webroot, plugin de Nginx/Apache o desafío DNS) y cómo evitar los errores más habituales al desplegar HTTPS en producción.

• En este artículo: método HTTP-01 frente a DNS-01, playbook de ejemplo con Nginx y checklist de requisitos.
• Al terminar: sabrás cómo programar renovaciones y hooks de despliegue sin downtime innecesario.
• Ideal para: equipos DevOps que ya usan Ansible para frontales web y quieren TLS gestionado como código.

¿Qué es Ansible Certbot?

Ansible Certbot es el patrón de automatización en el que Ansible instala y ejecuta Certbot (el cliente oficial de Let’s Encrypt) para emitir certificados TLS, configurar el servidor web y programar la renovación. No es un producto distinto de Certbot: es la forma de industrializar lo que harías a mano en una máquina, pero aplicado a decenas o cientos de hosts con el mismo playbook.

Las ventajas frente a scripts sueltos son claras: inventario versionado, idempotencia (re-ejecutar no rompe el estado), trazabilidad en CI/CD y coherencia con el resto de tu stack (por ejemplo, si ya usas Ansible Nginx o Ansible Apache para el frontal web).

• Emisión inicial: Certbot demuestra el control del dominio (HTTP-01 o DNS-01) y descarga la cadena de certificados.
• Instalación en el servidor: copia de fullchain.pem y privkey.pem (o uso directo de rutas gestionadas por Certbot).
• Renovación: certbot renew en cron o systemd timer; Ansible asegura que el job exista y que los permisos sean correctos.
• Integración con hardening: alinear ciphers, HSTS y cabeceras con políticas de seguridad; encaja con Ansible Security Hardening y capas perimetrales como Ansible Fail2ban.

Arquitectura de Ansible Certbot para Let’s Encrypt

Antes de escribir YAML, define cómo va a validar Let’s Encrypt tu dominio. Esa elección condiciona firewall, DNS y tiempo de despliegue.

HTTP-01 (recomendado cuando controlas el puerto 80): Certbot sirve un token bajo /.well-known/acme-challenge/. Es el camino más simple si Nginx o Apache ya escuchan en 80 y el DNS apunta al servidor. Con Ansible Certbot suele usarse el plugin --nginx o --apache, o certonly --webroot si prefieres no tocar la config del vhost en la primera pasada.

DNS-01 (imprescindible para wildcard *.dominio.com o cuando 80 está cerrado): Certbot crea un registro TXT en tu zona DNS. Requiere credenciales del proveedor (API de Cloudflare, Route53, etc.) y un rol o script que Ansible pueda invocar de forma segura (idealmente vía Ansible Vault o un backend de secretos).

En entornos híbridos, documenta por qué cada grupo de hosts usa un método u otro: mezclar estrategias sin criterio complica el soporte y las rotaciones de certificado. Un mismo inventario puede servir varios perfiles si parametrizas el método ACME en group_vars.

Requisitos previos para Ansible Certbot

Para que Ansible Certbot no falle a mitad del playbook, revisa esta lista antes del primer ansible-playbook:

• DNS: el FQDN debe resolver al servidor correcto (o al balanceador si termina TLS allí). Propagación lenta = validación fallida.
• Puertos: en HTTP-01, el puerto 80 debe llegar al host que ejecuta Certbot (o al nodo que sirve el desafío). Si solo tienes 443, necesitas DNS-01.
• Reloj: TLS es sensible al tiempo; NTP/Chrony correctos en todos los nodos.
• Paquetes: repositorio EPEL en RHEL-like, o la versión de Certbot soportada por tu distro; evita mezclar pip y paquetes del sistema sin pin de versión.
• Permisos: Certbot suele escribir bajo /etc/letsencrypt; el usuario que use el plugin de Nginx/Apache debe poder recargar el servicio.

Si despliegas aplicaciones en contenedores, revisa también Ansible Docker Deployment: el certificado puede generarse en el host y montarse como volumen, o generarse en un reverse proxy dedicado.

Playbook Ansible Certbot paso a paso

El flujo típico en HTTP-01 con Nginx sería: instalar Certbot y el plugin, asegurar un server block mínimo en :80 para el desafío, ejecutar Certbot en modo no interactivo y recargar Nginx. A continuación un ejemplo compacto que puedes adaptar a tus roles; sustituye dominios y rutas.

---
- name: Certbot Let's Encrypt con Nginx (HTTP-01)
  hosts: webservers
  become: true
  vars:
    certbot_admin_email: "[email protected]"
    certbot_domains:
      - "www.tudominio.es"
      - "tudominio.es"
    certbot_webroot: "/var/www/certbot"

  tasks:
    - name: Instalar Certbot y plugin nginx (Debian/Ubuntu)
      ansible.builtin.apt:
        name:
          - certbot
          - python3-certbot-nginx
        state: present
        update_cache: true
      when: ansible_os_family == "Debian"

    - name: Directorio webroot para desafío ACME
      ansible.builtin.file:
        path: "{{ certbot_webroot }}"
        state: directory
        owner: www-data
        mode: "0755"

    - name: Obtener certificados (primera emisión o renovación si aplica)
      ansible.builtin.command: >
        certbot certonly
        --webroot -w {{ certbot_webroot }}
        --email {{ certbot_admin_email }}
        --agree-tos --noninteractive --expand
        {% for d in certbot_domains %} -d {{ d }}{% endfor %}
      args:
        creates: "/etc/letsencrypt/live/{{ certbot_domains[0] }}/fullchain.pem"
      register: certbot_issue

    - name: Desplegar snippet SSL (gestiona tu template de Nginx)
      ansible.builtin.template:
        src: nginx-ssl.conf.j2
        dest: /etc/nginx/snippets/ssl-{{ certbot_domains[0] }}.conf
        mode: "0644"
      notify: Recargar Nginx

  handlers:
    - name: Recargar Nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

La clave idempotente está en creates: la primera corrida emite certificado; las siguientes pueden saltarse o puedes cambiar a un stat + condición si quieres forzar reemisión. Para renovaciones, confía en el timer de sistema que empaqueta Certbot o añade un cron que ejecute certbot renew --quiet y recargue el servicio web solo si hubo cambio (el hook --deploy-hook es ideal).

Referencias oficiales: documentación de Ansible, guía de Certbot y recomendaciones de Let’s Encrypt.

Renovación automática y hooks con Ansible Certbot

La emisión inicial es solo la mitad del trabajo: la otra mitad es que las renovaciones ocurran sin sorpresas. Los paquetes de Certbot suelen instalar un timer de systemd o una entrada de cron que ejecuta certbot renew dos veces al día; el propio cliente solo renueva cuando queda poco margen antes del vencimiento. Debes asegurar con Ansible que ese timer esté habilitado y que, si tu distribución no lo trae, lo crees tú de forma idempotente.

El punto crítico es el deploy hook: tras una renovación real (no un dry-run), quieres recargar Nginx o Apache para que cargue el nuevo fullchain.pem sin reinicio brusco. Un patrón habitual es certbot renew --deploy-hook "systemctl reload nginx" o un script que compruebe el código de salida. Si tienes varios servicios (por ejemplo, un broker MQTT o un API Gateway que lee los mismos ficheros PEM), encadena los reloads en ese hook y documenta el orden para evitar ventanas donde un servicio siga sirviendo material antiguo.

Entornos de staging y límites de tasa

Antes de martillar la API de producción de Let’s Encrypt, usa el entorno de staging: los certificados no son confiables para navegadores, pero te permiten validar DNS, firewall y playbooks sin consumir límites estrictos. Define una variable certbot_server que apunte al endpoint de staging en pruebas y cámbiala por inventario o por extra-vars al promocionar a producción. Así reduces incidentes del tipo “CI ejecutó veinte veces el mismo playbook y ahora tenemos bloqueo temporal”.

Los rate limits de Let’s Encrypt son una realidad operativa: muchos certificados duplicados para el mismo conjunto de dominios en poco tiempo pueden forzar una espera. Diseña tus pipelines para que fallen rápido con mensajes claros y no reintenten en bucle infinito.

Webroot frente a plugins nativos

El plugin --nginx o --apache modifica la configuración del servidor para completar el desafío: es cómodo al inicio, pero en equipos maduros a veces se prefiere certonly --webroot porque deja el control total del vhost en tus plantillas Jinja. Puedes combinar enfoques: primera pasada con webroot y bloques location dedicados al path ACME, y más adelante migrar a un modelo con terminación TLS en un único frontal. Lo importante es que una sola fuente de verdad defina los server_name y las rutas, para no duplicar lógica entre el rol de Certbot y el rol de Nginx.

Variables y roles recomendados en Ansible Certbot

Centraliza en group_vars o en Vault: correo de contacto ACME, lista de SAN (Subject Alternative Names), método de autenticación y proveedor DNS si aplica. Buenas prácticas con Ansible Certbot:

• Una cadena por línea de producto: separa certificados de staging y producción; Let’s Encrypt ofrece staging para pruebas sin límites estrictos.
• Hooks: --pre-hook / --post-hook para parar servicios que ocupen el puerto 80 solo si es inevitable; evita downtime largo.
• Notificaciones: integra fallos de renovación con tu sistema de alertas (correo, Slack, Prometheus).
• Versionado de configuración: el vhost SSL debe vivir en Git igual que el playbook; la automatización cubre el servidor, no sustituye el control de cambios.

Si reutilizas roles de la comunidad, revisa en Ansible Galaxy el mantenimiento del rol y la compatibilidad con tu familia de SO; a veces un rol mínimo propio es más claro que cinco capas de abstracción.

Optimización y buenas prácticas Ansible Certbot

Más allá de “que funcione el candado verde”, optimiza la operación diaria de Ansible Certbot:

• OCSP stapling: reduce latencia y carga en respondedores OCSP; configúralo en Nginx/Apache tras la emisión.
• Ciphers y protocolos: TLS 1.2+ y conjuntos modernos; alinea con tu política interna y prueba con ssl labs o herramientas similares.
• HSTS: solo actívalo cuando estés seguro de que todo el sitio servirá HTTPS; es difícil de revertir en clientes.
• Redirecciones: fuerza 80→443 de forma explícita; evita bucles con proxies y cabeceras X-Forwarded-Proto.
• Monitorización de caducidad: aunque Let’s Encrypt renueva a 60 días, vigila la fecha de expiración como red de seguridad.

En despliegues frecuentes, ejecuta el playbook en ventanas de mantenimiento o con serial en Ansible para no reiniciar todos los frontales a la vez.

Si tu organización separa red y aplicación, conviene que el equipo de redes confirme reglas en el firewall perimetral y en posibles WAF: un error típico es que el servidor “ve” el puerto 80 abierto localmente, pero desde Internet el tráfico se filtra antes de llegar al desafío ACME. Documenta en el runbook una prueba externa mínima (por ejemplo, solicitud HTTP al fichero de prueba) como gate previo al cambio.

Para equipos que ya usan AWX o Controller, el playbook de certificados puede lanzarse como Job Template con credenciales limitadas y aprobaciones: el beneficio no es solo técnico, sino de gobierno — saber quién autorizó un nuevo SAN en un certificado público es valioso en auditorías.

Troubleshooting Ansible Certbot

Cuando falla la validación, el mensaje de Certbot suele ser el mejor indicio. Problemas típicos en proyectos de automatización con Certbot:

• Timeout HTTP-01: firewall bloqueando 80, CDN cacheando mal el path del desafío, o DNS apuntando a otra IP. Verifica con curl desde fuera.
• Too many certificates: has golpeado rate limits; usa staging o reduce reintentos en bucles de CI.
• Plugin nginx/apache no encuentra bloque server: falta server_name que coincida con el dominio solicitado.
• Permisos: el usuario del servidor web no puede leer claves; revisa grupo ssl-cert o equivalentes.
• DNS-01: API con token revocado o zona equivocada; valida con dig TXT antes de relanzar Ansible.

Guarda los logs de /var/log/letsencrypt y la salida de Ansible en artefactos de pipeline para auditoría.

FAQ sobre Ansible Certbot

¿Puedo usar Ansible Certbot detrás de un balanceador? Sí, siempre que el desafío HTTP-01 llegue al nodo correcto o uses DNS-01 en el proveedor donde está la zona.

¿Es seguro guardar credenciales DNS en el repo? No en claro. Usa Vault o un secret manager e inyecta variables en runtime.

¿Cada cuánto debo ejecutar el playbook? Tras cambios de dominio o infra; la renovación la hace Certbot en el servidor, no necesitas Ansible diario salvo compliance que lo exija.

¿Ansible Certbot sustituye a un WAF? No; TLS cifra en tránsito. Sigue aplicando controles de aplicación y red según tu modelo de amenazas.

Conclusión: Ansible Certbot en producción

Ansible Certbot te da un camino reproducible para HTTPS con Let’s Encrypt: eliges el método de validación, codificas la instalación y la renovación, y conectas el resultado con el resto de tu automatización (Nginx, Apache, hardening, contenedores). Empieza por HTTP-01 en un entorno de staging, valida DNS y firewall, y solo entonces escala a producción con confianza.