www.feadulta.com, feadulta.com y wp-nuevo.feadulta.com, de Let's Encrypt y
validos hasta el 1-nov. Ya se puede subir la zona a Full (strict).
Lo que funciono es el plan B de Inma, porque la Configuration Rule que propuse
primero no se puede montar en su plan de Cloudflare: custom rule del WAF con
accion Skip para la ruta del reto, mas apagar Always Use HTTPS a nivel de zona
unos minutos.
Dos cosas que costaron tiempo y quedan anotadas:
acme.json escribe "main": "dominio" CON espacio. Un grep sin espacio da vacio
siempre y parece que no hay certificados. Los de hoy llevaban casi una hora
emitidos mientras mi bucle de vigilancia informaba de "sin novedad", y por eso
lanzamos un reintento que no hacia falta. Va el snippet que parsea el JSON.
Y se retira un riesgo que yo mismo habia documentado: el modo Full NO impide el
reto. Se temia que Cloudflare mandara la validacion al 443, donde el handler de
ACME no existe. Es falso y se midio: con Always Use HTTPS apagado, una peticion
HTTP a la ruta del reto a traves de Cloudflare devuelve 404 con 0 bytes y
server: cloudflare, o sea que reenvia al puerto 80 y responde Traefik. Mejor
quitarlo que dejar una advertencia falsa en un documento que va a leer otra
gente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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