Let's Encrypt no renueva solo: causas y solución

Si Let's Encrypt no renueva automáticamente tu certificado, la causa casi siempre es una de estas tres: el cron job (o systemd timer) que llama a certbot renew no está activo, el servidor no puede responder al desafío de validación de dominio, o un cambio reciente en la configuración de Apache/nginx rompió la ruta de validación.

Esta guía cubre cada causa con su diagnóstico y solución concreta.

Cómo funciona la renovación automática de Let's Encrypt

Let's Encrypt emite certificados válidos por 90 días. Certbot (el cliente oficial) está diseñado para intentar la renovación cuando quedan menos de 30 días de validez. Para ello, normalmente se instala una tarea programada:

systemd timer (distribuciones modernas): certbot.timer corre dos veces al día.
cron job (sistemas más antiguos o instalaciones manuales): una línea en /etc/cron.d/certbot o en el crontab del sistema.

Si alguno de estos mecanismos falla silenciosamente — o si el proceso de validación falla cuando sí intenta renovar — el certificado expirará sin avisar (salvo los correos de aviso de Let's Encrypt a los 20 y 7 días antes).

Diagnóstico: identificar por qué no renueva

1. Verificar que el timer/cron está activo

En sistemas con systemd:

systemctl status certbot.timer

El estado debe ser active (waiting). Si no aparece o está inactivo:

systemctl enable --now certbot.timer

En sistemas con cron, revisa:

cat /etc/cron.d/certbot

Deberías ver algo similar a:

0 */12 * * * root certbot -q renew

Si no existe ese archivo, instálalo o añade la línea al crontab del sistema.

2. Ejecutar la renovación en modo prueba

Sin esperar al siguiente ciclo automático, simula la renovación para ver si falla:

certbot renew --dry-run

Este comando no modifica ningún certificado real — solo verifica que el proceso funcionaría. Cualquier error que aparezca aquí es exactamente el que impide la renovación automática.

3. Revisar los logs de certbot

cat /var/log/letsencrypt/letsencrypt.log

Busca líneas con ERROR o FAILED. Los mensajes más comunes son:

Connection refused o Timeout — el servidor no es accesible desde Internet en el puerto 80.
404 Not Found en /.well-known/acme-challenge/ — el directorio de validación está bloqueado.
DNS problem: NXDOMAIN — el dominio no resuelve o cambió de IP recientemente.

Las causas más frecuentes y su solución

Puerto 80 bloqueado o redirigido antes de la validación

Let's Encrypt (método HTTP-01) necesita acceder a http://tudominio.com/.well-known/acme-challenge/ desde sus servidores de validación. Si tienes una regla en .htaccess o en Apache que redirige todo el tráfico HTTP a HTTPS antes de que certbot pueda responder, la validación falla.

Solución: excluye la ruta de validación de la redirección:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Certbot moderno (≥ 0.28) incluye un plugin que maneja esto automáticamente al usar --apache o --nginx. Si instalaste certbot con --webroot, la gestión de la exclusión es manual.

Firewall bloqueando el puerto 80

Aunque tu sitio solo sirva HTTPS, el proceso de validación HTTP-01 de Let's Encrypt necesita el puerto 80 abierto (no tiene que servir contenido, solo responder al challenge). Verifica:

curl -I http://tudominio.com/.well-known/acme-challenge/test

Si obtienes Connection refused o timeout, revisa las reglas de iptables, firewalld o el firewall de tu proveedor de hosting. La solución rápida:

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

Alternativamente, cambia al método de validación DNS-01 si no puedes abrir el puerto 80 (más avanzado pero funciona sin puerto 80).

Nombre de dominio o DNS cambiado recientemente

Si migraste el dominio a un nuevo servidor o cambiaste los DNS y la propagación aún no completó, Let's Encrypt no podrá verificar la propiedad del dominio. Verifica desde una herramienta externa que el dominio apunta a la IP correcta antes de volver a intentar la renovación.

Versión desactualizada de certbot

Certbot versiones muy antiguas pueden fallar con el API actualizado de Let's Encrypt. En sistemas basados en snap (la instalación recomendada actual):

snap refresh certbot

En instalaciones pip o paquetes del sistema, actualiza mediante el gestor de paquetes correspondiente.

Conflictos con el panel de control (cPanel, Plesk, DirectAdmin)

Si usas hosting compartido con cPanel o Plesk, estos paneles gestionan Let's Encrypt con su propia herramienta (AutoSSL en cPanel, Let's Encrypt SSL en Plesk). Si AutoSSL está en el servidor pero además instalaste certbot manualmente, pueden entrar en conflicto. En este caso:

En cPanel: ve a Seguridad → SSL/TLS → AutoSSL y revisa si hay errores de validación reportados ahí. El log de AutoSSL está en /var/cpanel/logs/autossl/.
En Plesk: ve a Websites & Domains → SSL/TLS Certificates y comprueba si la renovación está pendiente.

Lo más limpio en hosting compartido es dejar que el panel maneje los certificados y no instalar certbot por separado.

Si necesitas más contexto sobre la gestión de certificados SSL, consulta nuestra sección de seguridad SSL con guías paso a paso.

Forzar la renovación manual cuando urge

Si el certificado ya expiró (o está a punto de expirar) y necesitas renovarlo ahora mismo:

certbot renew --force-renewal

O para un dominio específico:

certbot certonly --force-renewal -d tudominio.com -d www.tudominio.com

Después de la renovación, recarga Apache o nginx para que cargue los nuevos archivos de certificado:

systemctl reload apache2
# o
systemctl reload nginx

Tabla de diagnóstico rápido

Síntoma en el log	Causa probable	Solución
`Connection refused`	Puerto 80 cerrado	Abrir puerto 80 en firewall
`404 on /.well-known/`	Redirección o bloqueo de ruta	Excluir la ruta del redireccionamiento
`DNS NXDOMAIN`	Dominio no resuelve	Verificar DNS / esperar propagación
`certbot.timer inactive`	Timer apagado	`systemctl enable --now certbot.timer`
Renovación sin error pero sin éxito	Certbot desactualizado	`snap refresh certbot`

Conclusiones clave

Let's Encrypt no renueva automáticamente cuando el systemd timer/cron está inactivo o cuando la validación HTTP-01 falla.
Usa certbot renew --dry-run para reproducir el error exacto sin modificar certificados.
El puerto 80 debe estar abierto para la validación HTTP-01, incluso si tu sitio solo sirve HTTPS.
Excluye /.well-known/acme-challenge/ de cualquier redirección HTTP→HTTPS en .htaccess.
En hosting compartido, deja que AutoSSL (cPanel) o el panel equivalente gestione los certificados.
Después de renovar manualmente, recarga siempre Apache o nginx para activar el nuevo certificado.

Si prefieres delegar la gestión de SSL y no volver a preocuparte por renovaciones, nuestro equipo en elenlace.com se encarga de la configuración completa y el mantenimiento continuo.

Preguntas frecuentes

¿Con cuánta anticipación intenta renovar certbot?

Certbot intenta renovar el certificado cuando quedan menos de 30 días de validez. Como Let's Encrypt emite certificados de 90 días, la ventana de renovación empieza aproximadamente a los 60 días. Si el primer intento falla, certbot lo reintentará en el siguiente ciclo del cron (normalmente 12 horas después).

¿Recibiré aviso antes de que el certificado caduque?

Sí. Let's Encrypt envía correos de aviso al email registrado durante la emisión del certificado: una notificación 20 días antes de la caducidad y otra a los 7 días. Si no los recibes, verifica que el email es correcto con certbot show_account y revisa tu carpeta de spam.

¿Puedo usar Let's Encrypt con un hosting que no tengo acceso SSH?

Sí, pero depende del panel. cPanel con AutoSSL y Plesk con su integración nativa gestionan Let's Encrypt sin necesidad de SSH. En DirectAdmin también existe integración nativa. Si el panel no lo soporta, necesitarás acceso SSH o usar el método de validación DNS-01 a través de la API de tu proveedor de DNS.

¿Por qué Let's Encrypt da error aunque el dominio carga bien en el navegador?

Los servidores de validación de Let's Encrypt acceden a tu dominio desde su infraestructura en Internet, no desde la misma red que tu navegador. Es posible que el dominio funcione desde tu red local (o con caché DNS) pero que los servidores de Let's Encrypt vean una IP diferente, un firewall, o una redirección que bloquea el challenge. Siempre prueba con curl -I http://tudominio.com/.well-known/acme-challenge/test desde un servidor externo.

¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.

Compara proveedores

Otros proveedores y guías que vale la pena comparar: