Aviso de Inma: en su plan las Configuration Rules no ofrecen "Always Use HTTPS"
ni "Security Level", asi que la regla del documento no se puede montar tal cual.
Se sustituye por lo que si se puede hacer: custom rule del WAF con accion Skip
para la ruta del reto, y apagar "Always Use HTTPS" a nivel de zona durante el
reintento.
Se anade ademas un riesgo que hay que tener presente ANTES de gastar el
reintento: con el modo SSL de la zona en Full, Cloudflare habla con el origen por
HTTPS. Si eso se aplica tambien a lo que le entra por HTTP, la peticion de Let's
Encrypt llegara al 443 de Traefik, donde el handler de ACME no existe, y volvera
a fallar. No se puede saber desde aqui sin apagar el ajuste, porque mientras este
encendido Cloudflare redirige en su borde y nunca contacta con el origen por el
80.
Va una tabla para leer el siguiente error sin discutirlo otra vez: si sale el
certificado, bien; si da 403, el Skip no coge esa ruta; si da 404, Cloudflare va
al 443 y toca pasar a DNS-01 en vez de seguir quemando validaciones.
Y se matiza lo de los visitantes: el 302 del origen solo los cubre si Cloudflare
reenvia por el 80. Si va al 443, quien entre por http se queda en http durante la
ventana. Inocuo para unos minutos, pero mejor decirlo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Documento para que lo pueda leer Inma sin tener que reconstruir la conversacion.
Lo esencial: el lado del servidor esta bien. Traefik intercepta la ruta del reto
en el entrypoint http y no la redirige, y se ve en que ese 404 viene vacio y sin
cabecera server mientras cualquier otra ruta da 302. El problema esta delante, en
el borde de Cloudflare: el reto acaba llegando por HTTPS y lo para un 403.
Se recoge tambien por que dos personas midiendo lo mismo obtuvieron resultados
distintos, que es lo que mas tiempo nos ha costado: Cloudflare devuelve 403 a
nuestras IPs para cualquier hostname de feadulta, y con el User-Agent de Let's
Encrypt deja pasar el bloqueo y entonces aparece el 301. La forma del token no
cambia nada. Conclusion util: el unico testigo que vale es lo que reporta Let's
Encrypt, no nuestros curl.
Y un aviso que puede hacernos perder la tarde: Let's Encrypt permite 5
validaciones fallidas por hostname y hora, www toco el limite a las 11:47 UTC y
cada redeploy quema tres. Reintentar antes de que pase la hora falla por rate
limit aunque la regla este bien puesta, y nos haria creer que no funciona. Va el
procedimiento en orden: primero la regla, luego esperar, luego un solo reintento.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rafa