La renovación automática es la promesa de que puedes dejar de pensar en los certificados. Cumple esa promesa casi siempre, y por eso el día en que falla es una sorpresa. El sitio funcionaba ayer y hoy los navegadores muestran una advertencia a pantalla completa.
El motivo es que la «renovación automática» no es una sola cosa. En un certificado emitido mediante el protocolo automatizado habitual (ACME), que usan Let's Encrypt y otros, varios pasos tienen que funcionar siempre. Para saber cómo funcionan los certificados en general y cómo leer sus fechas, consulta Cómo evitar que caduque un certificado SSL. Esta guía trata el caso en que la automatización estaba activada y el certificado caducó de todos modos.
La cadena de pasos
- Arranca una tarea. Algo se ejecuta según un calendario: un temporizador, una entrada de cron o una tarea integrada de tu alojamiento.
- El cliente de renovación pide un certificado nuevo. Contacta con la autoridad de certificación.
- La autoridad comprueba que controlas el nombre. Hay que responder a un desafío, por web o en el DNS.
- El certificado nuevo se guarda en un archivo o en un almacén.
- El servidor lo carga. Muchos servidores leen el archivo solo al arrancar o al recargar.
- Los visitantes lo reciben. En cada dirección, puerto y capa que presenta un certificado.
Si el paso 1 nunca se ejecuta, nada más importa. Si el paso 5 nunca ocurre, el archivo renovado queda sin usar. Todos los fallos se ven igual desde fuera: un certificado antiguo que caduca.
Dónde se rompe
| Paso | Qué sale mal | Una señal típica |
|---|---|---|
| 1 | La tarea programada se eliminó, se desactivó o nunca se trasladó tras una migración o una actualización del servidor | Nada en el registro de renovación durante semanas |
| 2 | El cliente es demasiado antiguo, o su cuenta o su acceso ya no existen | Errores en el registro de renovación sobre la cuenta o la solicitud |
| 3 | El paso de validación dejó de funcionar: un cortafuegos modificado, una redirección que bloquea la ruta que usa el desafío, un registro DNS o un acceso a API que se cambió | Un error «challenge failed» o «unauthorized» |
| 3 | Demasiadas solicitudes fallidas o repetidas alcanzaron el límite de frecuencia de la autoridad | Un mensaje de límite de frecuencia; las renovaciones fallan hasta que pasa el límite |
| 4 | No se pudo escribir el archivo, o falló un gancho que lo copia | El archivo nuevo existe en una carpeta y no en otra |
| 5 | El servidor nunca se recargó, o lee un archivo distinto del que actualiza el cliente | El archivo muestra una fecha nueva, el navegador muestra una antigua |
| 6 | El certificado lo presenta otra capa: un balanceador de carga, una CDN, un servidor de correo, otro puerto, otro host virtual | Una dirección está renovada y otra no |
Los hilos de foros y las guías de alojamiento describen todos estos casos. Las historias más comunes son una tarea que desapareció tras un cambio y un certificado que se renovó pero un servidor que siguió sirviendo la copia antigua.
Encuentra el eslabón roto
Trabaja desde el final, porque eso es lo que ven los visitantes.
Qué se está sirviendo
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject
Esto imprime las fechas de inicio y de fin del certificado que presenta el servidor en esa dirección. Si la fecha de fin está cerca o ya pasó, el certificado no está renovado donde importa. Ejecútalo para cada nombre y puerto que uses, no solo para el principal.
Qué hay en el disco
Con Certbot, la lista de certificados y sus fechas de vencimiento se obtiene con:
sudo certbot certificates
Si el archivo tiene una fecha nueva y el servidor muestra una antigua, el problema está en el paso 5 o 6: el servidor no se recargó o lee otro archivo. Si el propio archivo es antiguo, el problema está en los pasos 1 a 4.
Si la tarea se está ejecutando
En un sistema que usa temporizadores, systemctl list-timers lista las tareas programadas. Busca la de renovación y cuándo se ejecutó por última vez. Una configuración de cron simple está en crontab -l y en los archivos de /etc/cron.d/.
Si la renovación funciona ahora
sudo certbot renew --dry-run
Una ejecución de prueba recorre los pasos sin reemplazar nada. Un error aquí es el mismo error que bloqueó la renovación real, y nombra el paso.
Note
Estos comandos suponen Certbot en un servidor Linux. Otros clientes y paneles de alojamiento tienen sus propias herramientas. El orden sigue siendo el mismo: qué se sirve, qué se guarda, si la tarea se ejecuta, si la renovación funciona.
Corrige y previene
- Corrige la causa y luego renueva una vez a mano para no esperar a la siguiente ejecución programada.
- Recarga el servidor después de cada renovación. La mayoría de los clientes pueden ejecutar un comando tras una renovación correcta. Sin él, un archivo renovado puede quedar sin usar.
- Haz una lista de todos los lugares donde vive un certificado. El sitio web, el servidor de correo, el host de la API, el host de pruebas, el balanceador de carga. Cada uno necesita su propia renovación y su propia comprobación.
- No te fíes del silencio de la propia tarea. Una tarea que falla en silencio se ve igual que una que funciona. La única prueba de que la renovación funcionó es la fecha nueva en el certificado que realmente se sirve.
- Mantén una alerta independiente. Un aviso que viene de fuera, con antelación a la fecha de fin, no depende de que funcione ningún paso de la cadena.
Qué añade un monitor
Un monitor que se conecta a tu dirección desde fuera lee el certificado que recibirían los visitantes. Ese es el paso 6, el único que no puedes simular desde dentro del servidor, y detecta todos los fallos anteriores, sea cual sea el paso que los causó.
UptimeWire comprueba el certificado de cada dirección https aproximadamente cada seis horas y te avisa por correo y por Telegram, dentro del plazo que elegiste para ese sitio web, de 1 a 60 días antes de que caduque. El aviso se envía una vez. Es un recordatorio para que actúes: UptimeWire no renueva, instala ni arregla certificados, y no averigua por qué falló una renovación. Comprueba el certificado de la dirección que añades, así que otros nombres y puertos necesitan sus propias entradas.
Como los certificados se comprueban aproximadamente cada seis horas, un aviso llega algunas horas después de cruzar el umbral, no en ese momento exacto. Para un certificado que se renueva automáticamente, un plazo de aviso de 14 o 30 días funciona como red de seguridad: si salta, la automatización ya ha perdido su oportunidad y aún te queda tiempo para arreglarlo antes de que los visitantes se vean afectados. Consulta monitorización de la caducidad de certificados SSL para ver el flujo de trabajo cuando llega un aviso.
Lista de comprobación
- ¿Qué certificado sirve cada dirección y puerto, y cuándo termina?
- ¿La tarea de renovación está programada y cuándo se ejecutó por última vez?
- ¿Una ejecución de prueba termina bien, o qué paso nombra?
- ¿Se recarga el servidor después de la renovación?
- ¿Se renueva cada nombre, subdominio y servicio que presenta un certificado?
- ¿Hay un aviso desde fuera, configurado con mucha antelación a la fecha de fin?