Renovar SSL automáticamente con Certbot y cron en Linux

Los certificados emitidos por Let’s Encrypt tienen una validez de 90 días — una decisión intencional del proyecto para forzar la automatización y reducir la ventana de exposición en caso de compromiso. La renovación manual cada 60-80 días es insostenible en producción: basta un viaje, una guardia sobrecargada o un servidor olvidado para que TLS expire y el sitio empiece a devolver ERR_CERT_DATE_INVALID en el navegador de los clientes.

Este tutorial es para sysadmins y desarrolladores que ya tienen Certbot instalado y al menos un certificado emitido, y quieren garantizar que la renovación se ejecute sin intervención, recargue el servidor web sin downtime y avise si algo se rompe. Vamos a cubrir los dos enfoques — cron clásico y systemd timer — elegir cuándo usar cada uno, configurar deploy hooks para recargar Nginx/Apache y armar un monitoreo básico.

Tiempo estimado de ejecución: 15 a 25 minutos, dependiendo de cuántos dominios gestiones y si vas a configurar alertas personalizadas.

Requisitos previos

Confirma la versión de Certbot y la presencia de al menos un certificado antes de continuar:

certbot --version
sudo certbot certificates

La salida de certbot certificates debe listar cada certificado con nombre, dominios cubiertos y fecha de expiración. Si no aparece nada, emite un primer certificado antes de configurar la automatización — esta documentación asume que la etapa de emisión inicial ya fue realizada.

Verificando si el timer systemd ya está activo

En distros modernas el paquete certbot instala automáticamente una unit systemd que se encarga de la renovación — antes de tocar cron, confirma si ya está corriendo. La mayoría de las instalaciones Ubuntu 22.04+ no necesita ningún cron manual.

systemctl list-timers --all | grep -i certbot

systemctl cat certbot.timer

systemctl cat certbot.service

Configurando la renovación vía cron tradicional

Si estás en una distro antigua, en un servidor sin systemd o simplemente prefieres cron, usa este enfoque. En distros modernas, deshabilita el timer antes para evitar dos ejecuciones concurrentes.

sudo systemctl disable --now certbot.timer

sudo crontab -e

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3,15 * * * /usr/bin/certbot renew --quiet

sudo crontab -l

Configurando deploy hook para recarga sin downtime

Renovar el certificado no basta — Nginx o Apache siguen usando el cert antiguo cargado en memoria hasta recibir la señal para recargar. Los deploy hooks resuelven esto elegantemente.

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload apache2
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh

sudo certbot renew --dry-run

Monitoreando la renovación

Automatización sin observabilidad es una trampa — descubrir que el cert expiró por el error del navegador es el peor escenario posible. Arma un check activo que avise antes.

sudo tee /usr/local/bin/check-ssl-expiry.sh > /dev/null <<'EOF'
#!/bin/bash
THRESHOLD_DAYS=20
ALERT_EMAIL="[email protected]"

for cert in /etc/letsencrypt/live/*/cert.pem; do
  domain=$(basename "$(dirname "$cert")")
  end_date=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
  end_epoch=$(date -d "$end_date" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (end_epoch - now_epoch) / 86400 ))

  if [ "$days_left" -lt "$THRESHOLD_DAYS" ]; then
    echo "ALERTA: $domain expira en $days_left días" | \
      mail -s "SSL expirando: $domain" "$ALERT_EMAIL"
  fi
done
EOF
sudo chmod +x /usr/local/bin/check-ssl-expiry.sh

echo "30 8 * * * /usr/local/bin/check-ssl-expiry.sh" | sudo tee -a /etc/crontab

Verificación final

Ejecuta los comandos siguientes para confirmar que toda la configuración está activa:

sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot
ls -la /etc/letsencrypt/renewal-hooks/deploy/
sudo /usr/local/bin/check-ssl-expiry.sh

El dry-run debe pasar sin errores. El timer (si optaste por systemd) debe estar activo. Los hooks deben ser ejecutables. El script de verificación no debe emitir alerta — si lo hace, el cert está en ventana crítica y necesitas investigar los logs en /var/log/letsencrypt/letsencrypt.log.

Resolución de problemas

”Failed authorization procedure” en el renew

Causa común: puerto 80 bloqueado por firewall o redirigido a 443 sin excepción para la ruta /.well-known/acme-challenge/. Certbot necesita servir el desafío HTTP-01 en esa ruta. Confirma con curl http://tu-dominio/.well-known/acme-challenge/test — debe devolver 404 de tu servidor, no error de conexión. Si fuerzas redirect global a HTTPS, agrega una excepción para esa ruta en Nginx.

”Hook command exited with code 1”

El script del hook devolvió error. Ejecútalo manualmente para depurarlo: sudo bash /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh. Errores típicos: nginx config inválida (nginx -t primero), servicio no corriendo o permisos incorrectos en el script.

El timer aparece activo pero nunca renueva

Verifica la hora del servidor con timedatectl — si el reloj está incorrecto, el timer se dispara pero certbot rechaza la operación. Sincroniza con sudo systemctl restart systemd-timesyncd. Otro caso: el cert aún no está en la ventana de 30 días antes de expirar; certbot lo ignora silenciosamente. Fuerza con --force-renewal solo si confirmaste otras causas.

Próximos pasos

Con la renovación automatizada y monitoreada, considera estos próximos pasos para aumentar la robustez de tu setup TLS:

• Configurar OCSP stapling en Nginx — reduce la latencia de validación del cert en el navegador y disminuye la carga en los servidores OCSP de Let’s Encrypt.
• Evaluar wildcard certificates con desafío DNS-01 — útil si gestionas muchos subdominios; requiere un plugin DNS específico de tu proveedor.
• Implementar HSTS preload después de confirmar la estabilidad de la renovación — difícil de revertir, así que actívalo solo cuando la automatización haya corrido por al menos 2 ciclos completos.
• Centralizar los logs de renovación en un sistema de observabilidad — útil en flotas de servidores donde verificar cada máquina individualmente no escala.

Si estás llevando esto a producción, una VPS Hostini ya viene con Ubuntu LTS actualizado, SSH endurecido por defecto y tráfico con protección DDoS — base sólida para automatizaciones de TLS sin sorpresas en el kernel o en la red.