docs: el plan de Cloudflare no permite la regla que propuse

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>
This commit is contained in:
2026-08-03 08:42:14 -04:00
parent f6170b70b1
commit 20528f0c5e
@@ -64,15 +64,49 @@ El problema está **delante**, en el borde de Cloudflare, no en Hetzner.
## El arreglo ## El arreglo
**Cloudflare → Rules → Configuration Rules.** Una regla acotada a la ruta del reto: ⚠️ **Corrección (Inma, 3-ago): en este plan de Cloudflare las Configuration Rules NO ofrecen
"Always Use HTTPS" ni "Security Level".** Los ajustes disponibles son Automatic HTTPS Rewrites,
Browser Integrity Check, Disable RUM, Disable Zaraz, Email Obfuscation, Fonts, Hotlink Protection,
I'm Under Attack, Opportunistic Encryption, Polish, Request/Response Body Buffering, Rocket Loader y
SSL. **La regla no se puede montar así.**
- **Ámbito:** `*feadulta.com/.well-known/acme-challenge/*` ### Lo que sí se puede hacer
- **Always Use HTTPS → Off** — para que el reto se complete por el puerto 80, donde Traefik lo atiende
- **Security Level → Essentially Off** (o una regla WAF de tipo *Skip* para esa ruta) 1. **Custom rule del WAF con acción *Skip*** para `/.well-known/acme-challenge/` — quita el 403.
2. **Apagar "Always Use HTTPS" a nivel de zona** durante el reintento, y volver a encenderlo
después.
Es una excepción mínima y acotada: esa ruta no sirve contenido, solo tokens de un solo uso que el Es una excepción mínima y acotada: esa ruta no sirve contenido, solo tokens de un solo uso que el
propio Traefik genera y valida. propio Traefik genera y valida.
### ⚠️ Puede que aun así no salga, y conviene saber por qué antes de intentarlo
Con el modo SSL de la zona en **`Full`, Cloudflare habla con el origen por HTTPS**. Si eso se aplica
también a las peticiones que le entran por HTTP, entonces al apagar "Always Use HTTPS" la petición
de Let's Encrypt llegará igualmente al **443** de Traefik, donde **el handler de ACME no existe** —y
volverá a fallar, ahora con un 404 en vez de un 403.
No se puede determinar desde aquí sin apagar el ajuste: mientras "Always Use HTTPS" esté encendido,
Cloudflare redirige en su borde y **nunca llega a contactar con el origen por el puerto 80**, así que
no hay forma de observar qué puerto usaría.
**Cómo distinguir los dos casos en el siguiente intento**, mirando el error de Traefik:
| lo que reporte Let's Encrypt | qué significa | qué hacer |
|---|---|---|
| sale el certificado | Cloudflare reenvía por el 80 y Traefik atiende | nada más |
| `403` | el *Skip* del WAF no está cogiendo esa ruta | revisar el ámbito de la regla |
| **`404`** | **Cloudflare va al 443 del origen**: HTTP-01 no puede funcionar con la zona en `Full` | **pasar a DNS-01, dejar de quemar validaciones** |
### Sobre los visitantes durante la ventana
Apagar "Always Use HTTPS" unos minutos es inocuo, pero **no exactamente por el motivo que parece**.
Si Cloudflare reenviara por el 80, Traefik devuelve un 302 a HTTPS por su cuenta (medido) y el
visitante acaba igual. Si Cloudflare va al 443, ese 302 no llega a dispararse y **un visitante que
entre por `http://` se quedará en `http://`** — con el contenido correcto y cifrado hasta Cloudflare,
pero sin subir a HTTPS. Para una ventana de minutos no tiene consecuencias, pero que nadie se
extrañe si lo ve.
### Alternativa de fondo, para más adelante ### Alternativa de fondo, para más adelante
Pasar Traefik a validación **DNS-01** con el token de Cloudflare que ya tenemos Pasar Traefik a validación **DNS-01** con el token de Cloudflare que ya tenemos