Renovación Let's Encrypt: los tres fallos clásicos

La renovación automática de certificado tiene una personalidad muy suya: funciona impecablemente durante meses, luego se detiene, y no se lo dice a nadie. El comando sigue ejecutándose a su hora. Simplemente termina en error, en un archivo de registro que nadie abre. Estas son las tres formas en que se rompe realmente, y la única verificación que las atrapa a las tres.

Las tres averías, en una tabla

La tercera línea es la que sale más cara, precisamente porque el registro parece perfecto. Una supervisión que lee el registro de renovación declara pues que todo va bien mientras sus visitantes ven una pantalla roja.

1. El desafío de validación ya no alcanza su servidor

Para confirmar que usted controla el dominio, la autoridad de certificación pide un archivo bajo /.well-known/acme-challenge/… en su sitio. Su servidor debe servirlo, en HTTP simple, sin interferencia.

Lo que rompe eso, meses después de la instalación:

• Una redirección global hacia HTTPS o hacia un nuevo dominio, añadida por excelentes razones, y que atrapa también la ruta del desafío.
• Una regla de cortafuegos o de WAF que se pone a filtrar las rutas desconocidas, o que bloquea las direcciones desde las que llega la validación.
• Una ruta atrapatodo de framework que convierte cada URL desconocida en página 404, incluido el archivo de desafío, que ahora devuelve un 404 en una bonita maquetación.
• Una protección antirrobots instalada delante del sitio, que presenta una página de espera a todo cliente que no ejecuta JavaScript.

El comando de renovación no ha cambiado. Su entorno sí. Es lo que hace difícil imputar esta avería: nadie ha tocado el certificado, y sin embargo ya no se renueva.

La prueba cabe en una línea, desde cualquier máquina:

mkdir -p /var/www/html/.well-known/acme-challenge && echo ok > /var/www/html/.well-known/acme-challenge/test
curl -sI http://ejemplo.es/.well-known/acme-challenge/test | head -n 1

La respuesta esperada es 200. Un 301 hacia HTTPS ya es un problema en ciertas configuraciones, y un 403 o un 404 lo es siempre.

2. El DNS se ha movido

Si renueva un certificado comodín, la validación pasa por un registro DNS en vez de por un archivo. Eso supone una clave de API en su proveedor de DNS, puesta en un archivo de configuración, y que caduca o se revoca en silencio el día en que alguien rota las credenciales.

Tres variantes de la misma historia:

• La clave fue revocada durante una limpieza de seguridad, seis meses antes.
• El dominio fue transferido a otro registrador, y nadie pensó en informar al script.
• Los servidores de nombres han cambiado, la zona se gestiona ahora en otro sitio, y el script escribe concienzudamente su registro en una zona que ya nadie consulta.

En los tres casos, el error es explícito en el registro. Aún hace falta que alguien lo abra, y ahí está todo el problema.

3. La renovación ha funcionado, el despliegue no

Es la versión cruel. El nuevo certificado está en el disco, con fecha de hoy, perfectamente válido. Su servidor web sigue presentando el antiguo, porque no ha sido recargado desde su arranque.

Nada en el registro de renovación parece anormal. El archivo está ahí. Y sus visitantes reciben de todos modos la advertencia de seguridad a pantalla completa.

La causa es casi siempre un gancho de recarga ausente o silencioso:

# La recarga debe formar parte de la renovación, no de un gesto manual
--deploy-hook "systemctl reload nginx"

Dos trampas que conviene conocer. Un gancho que falla no hace fallar la renovación: deja un mensaje en el registro y devuelve el control. Y un servicio que necesita un reinicio completo, en vez de una recarga, no toma el nuevo archivo; es frecuente en las configuraciones que terminan el TLS fuera del servidor web, tras un proxy o un balanceador de carga, donde el certificado debe empujarse en dos sitios.

La cuarta avería, más rara y más desconcertante

Las tres anteriores vienen de su instalación. Esta viene de otro sitio, y desconcierta porque el comando es correcto y el servidor es irreprochable.

Se ha alcanzado la cuota. Las autoridades de certificación limitan el número de certificados emitidos para un mismo dominio en un periodo dado. Rara vez se llega en funcionamiento normal, y muy fácilmente en bucle de depuración: diez intentos de reemisión en una tarde, y ahí está usted bloqueado una semana con un certificado caducado en producción. Es la razón de ser del ensayo en seco, que no consume nada.

La clave de cuenta ha desaparecido. Una reinstalación del servidor, una restauración parcial, un contenedor reconstruido sin su volumen: el cliente ya no encuentra la cuenta que poseía los certificados, y empieza de cero sin decirlo con claridad.

El dominio ya no resuelve hacia usted. Un registro modificado, una migración en curso, un cambio mal terminado. La validación falla porque aterriza en otra máquina, lo cual es exacto y nada tiene que ver con el certificado.

Diagnosticar en tres comandos

certbot renew --dry-run                 # repite toda la renovación sin consumir cuota
curl -sI http://ejemplo.es/.well-known/acme-challenge/test   # ¿pasa el desafío?
echo | openssl s_client -connect ejemplo.es:443 2>/dev/null | openssl x509 -noout -dates

El primero atrapa las averías 1 y 2. El tercero atrapa la avería 3, y es el único que dice lo que el público recibe realmente.

Y si solo quieres saber lo que el público recibe ahora mismo, sin abrir un terminal, la página que lee un certificado responde a esa pregunta exacta con una dirección.

Lo que no hay que hacer durante la avería

No reemita en bucle: así es como un problema reparable se convierte en un problema de una semana. No corte HTTPS para «volver a poner el sitio en línea»: todos los enlaces de la web que apuntan a sus direcciones en https:// se romperían, y los navegadores memorizan durante mucho tiempo esa preferencia. Y no instale un certificado autofirmado como apaño: produce exactamente la misma página roja, con las mismas consecuencias, más un segundo problema que deshacer después.

La verificación que atrapa las tres

Cada una de esas averías es invisible desde dentro y evidente desde fuera. Así que mire desde fuera: abra una conexión TLS hacia su propio nombre de host y lea la fecha de caducidad del certificado realmente servido.

Esa sola medida cubre de golpe un desafío fallido, un problema de DNS y una recarga que falta, porque las tres acaban en el mismo sitio: un certificado viejo que se sigue presentando al público. Tiene además el mérito de no suponer nada de su instalación, lo que la mantiene válida tras un cambio de alojador o de pila técnica.

Alerte a treinta días, siete días y un día. Treinta dejan sitio para depurar con calma; uno atrapa la recarga que nunca tuvo lugar. Una verificación diaria basta de sobra, y es un caso en el que aumentar la frecuencia no aporta nada: una fecha de caducidad no cambia de una hora a otra.

Dos costumbres que valen la pena

Renovar con margen. A sesenta días en un certificado de noventa, un fallo le deja un mes en vez de una tarde. Es el ajuste por defecto de la mayoría de los clientes, y es uno de los pocos valores por defecto que no hay que tocar bajo ningún concepto.

Probar la renovación, no solo el certificado. El ensayo en seco existe en casi todos los clientes. Lanzarlo una vez al mes convierte una avería silenciosa en una avería conocida, meses antes de que cuente. Y como nadie más le avisará, es su única alerta anticipada.

Cuando ya ha caducado

No busque primero la causa. Renueve y recargue, ponga el sitio en estado, y haga la investigación después: es el mismo orden que los quince primeros minutos de un incidente, por la misma razón, a saber, que un sitio bloqueado cuesta algo cada minuto mientras usted comprende.

Nada de esto cambia su posicionamiento, de paso: HTTPS pesa mucho menos para los motores de lo que el pánico sugiere. Cuenta para la persona que no puede abrir su sitio.