Let’s Encrypt emite certificados por noventa días y los renueva automáticamente, razón por la cual se deja de pensar en ellos una semana después de configurarlos. El problema es que la renovación automática falla en silencio: nadie ve los errores, y tres meses después el sitio recibe a sus visitantes con una advertencia del navegador. Desde 2025, Let’s Encrypt ya no envía avisos de caducidad por correo, así que también ha desaparecido el último recordatorio externo.

A continuación, los motivos por los que la renovación deja de funcionar, en orden de frecuencia decreciente.

1. El certificado se renovó y el servicio no lo releyó

El más frecuente. certbot renew funcionó, el archivo nuevo está en el disco, y nginx o Apache siguen con el antiguo en memoria, entregándolo a los visitantes hasta que se recargue la configuración. Formalmente todo está bien; de hecho, el sitio tiene un certificado caducado.

Se cura con un gancho que se ejecuta tras una renovación correcta:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Eso se escribe una vez en el archivo de renovación (/etc/letsencrypt/renewal/example.com.conf, sección [renewalparams], línea renew_hook) y a partir de ahí funciona solo.

2. Cambió el servidor web y la validación no

La validación HTTP-01 exige que un archivo de /.well-known/acme-challenge/ se sirva por HTTP simple. Suele romperse así:

  • se añadió a la configuración una redirección incondicional de HTTP a HTTPS: la validación se va por la redirección y no pasa;
  • apareció una regla location ~ /\. con deny all que cierra todos los directorios con punto, .well-known incluido;
  • la raíz del sitio se mudó y en los ajustes de certbot quedó el antiguo --webroot-path;
  • se activó un bloqueo por países o una autenticación básica que se llevó por delante también al servidor de validación.

El orden correcto en la configuración: primero un location propio para /.well-known/acme-challenge/ y solo después la redirección general.

3. El temporizador está apagado

La renovación la lanza un temporizador de systemd o una tarea de cron, y ambas cosas pueden desactivarse por descuido durante una depuración o perderse en una mudanza de servidor.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

El segundo comando ejecuta un ciclo de renovación completo en modo de prueba sin gastar su cuota. Es la única comprobación que responde por adelantado a «¿se renovará dentro de un mes?» en lugar de a posteriori.

4. Un dominio ya no apunta aquí

El certificado cubre cinco dominios, uno de ellos se ha mudado a otro alojamiento, el DNS ha cambiado. La validación de ese dominio deja de pasar, y certbot no renueva el certificado entero, con los cuatro dominios que sí funcionan. Los dominios sobrantes hay que quitarlos del certificado, no ignorarlos junto con el mensaje.

5. Ha topado con los límites

Let’s Encrypt limita el número de certificados por dominio y semana. Suele ser consecuencia del bucle «no ha salido, lo intento otra vez» durante la depuración. Para experimentos existe un servidor de pruebas (--dry-run o --test-cert), y hay que usarlo antes de agotar el límite, no después.

Compruebe lo que se entrega, no lo que está guardado

Toda comprobación basada en archivos tiene el mismo defecto: el archivo puede estar fresco mientras el visitante recibe el certificado antiguo. Mire desde el lado del cliente:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

La opción -servername es imprescindible: sin ella, en un servidor con varios sitios obtendrá el certificado del primer host virtual que aparezca y no el que buscaba. En la salida, notAfter es la fecha real de caducidad.

Aproveche para comprobar la cadena:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Si solo hay un certificado, el intermedio no se está entregando. Los navegadores suelen perdonar esa configuración —construyen la cadena por su cuenta—, pero curl, las aplicaciones móviles y los clientes en Java fallarán la validación. Es el clásico «a mí se me abre todo y al cliente no le funciona».

Cuántos días de aviso

Treinta días son un primer umbral razonable: es también lo que queda cuando certbot empieza los intentos de renovación, así que si para entonces no ha pasado nada, el mecanismo está roto. Catorce días son la segunda señal, la que ya exige actuar hoy. Siete son una urgencia.

Lo importante es seguir todos los certificados a la vez, incluidos los que no vienen de Let’s Encrypt: los comprados por un año son los que se olvidan con más seguridad, porque en un año todos han olvidado tanto su existencia como a qué buzón llegan los avisos. Una página con los dominios, las fechas y los días restantes cierra la cuestión por completo, como en la demostración de abajo.