Sí, el desafío HTTP-01 funciona en conjunto con Cloudflare en modo “nube naranja”. Pero no funciona a través de HTTPS, el desafío HTTP-01 solo funciona a través del puerto 80, y:
Muchas personas que usan Cloudflare configuran Cloudflare para redirigir automáticamente HTTP a HTTPS, y eso hace que el puerto 80 en el servidor de origen no esté disponible, y eso impide que los desafíos HTTP-01 funcionen.
Así que si no habilitas esas redirecciones, entonces funcionará.
Así que, estrictamente hablando, esto no es cierto.
Let’s Encrypt fallará si Cloudflare está configurado para redirigir el tráfico en el puerto 80 antes de que llegue al servidor de origen.
Estoy de acuerdo, sin embargo, dado que la seguridad de TI está más presente que nunca y la gente empieza a trabajar más con productos de Confianza Cero, de los cuales CF Tunnel forma parte, veremos y deberíamos ver un aumento en la utilización de este tipo de tecnología, por eso lo mencioné.
Creo que no entendiste cómo funciona el desafío HTTP-01 de LE.
Busca el token que certbot u otra variante del cliente LE colocan, la mayoría de las veces, en la subcarpeta .well-known del servidor web.
Pero no está codificado para iniciar la solicitud en el puerto 80, ignorar cualquier redirección de código HTTP y fallar por completo si no puede encontrar el token.
El desafío HTTP-01 es capaz de seguir las redirecciones HTTP (por lo tanto, 301 y 302) y, por lo tanto, puede leer la carpeta .well-known a través de 443 y HTTPS.
Y la razón por la que funciona con Cloudflare Universal SSL CON Redirección (y Cloudflare Tunnel) es que Cloudflare responde en lugar del servidor web en el Puerto 80, redirige la solicitud a 443, donde LE puede leer el token y la CA puede emitir el certificado.
Diagrama de alto nivel del flujo:
Certbot inicia HTTP-01
→ Publica la solicitud de certificado a la CA y coloca el token en .well-known
→ La CA inicia GET para el Token en FQDN puerto 80
→ CF redirige al puerto 443 y asegura la solicitud con su certificado Universal SSL
→ La solicitud se reenvía al servidor web (a través de CF Tunnel o directo)
→ La CA puede obtener el token en .well-known porque el puerto 443 puede presentar el token de la misma manera que lo harían HTTP y el puerto 80
→ La CA publica los datos RAW del certificado y Certbot crea los archivos
Creo que lo entiendo bastante bien. Tienes razón, se puede redirigir a HTTPS, pero depende de la configuración de Cloudflare y de la configuración del servidor web si eso funcionará o no, ya que inicialmente no habrá un certificado válido en el servidor de origen.
Sí, se pueden redirigir a un puerto diferente, pero los desafíos HTTP-01 siempre deben comenzar en el puerto 80.
El desafío HTTP-01 solo se puede realizar en el puerto 80. Permitir que los clientes especifiquen puertos arbitrarios haría que el desafío fuera menos seguro, por lo que no está permitido por el estándar ACME.
Estoy de acuerdo, solo señalé tu inexactitud de que nunca funcionará directamente.
La cita de mi oración que has ejecutado aquí es bastante maliciosa, ya que sugiere la circunstancia incorrecta de la discusión e implica otro significado. Mi oración completa fue
y la parte importante de mi oración fue la combinación de “codificado para iniciar la solicitud en el puerto 80” Y “ignora cualquier redirección HTTP” Y “falla rotundamente”, ya que dijiste
y esto implica que la razón por la que falla el desafío HTTP-01 es solo la redirección, lo cual no es cierto.
Además, estrictamente hablando, una redirección no hace que el puerto 80 esté “no disponible”.
Hace que el puerto 80 del servidor de origen no esté disponible para todo el tráfico dirigido al nombre de host.
No me gusta el tono actual de la conversación en este tema, así que lo dejaré de seguir.
Mi opinión sobre Cloudflare en combinación con Discourse se puede resumir como “mucha gente aparentemente no puede configurarlo correctamente, por lo que en general recomendaría no habilitarlo. Si desea usarlo para protección contra DDoS, entonces recomendaría habilitarlo solo con configuraciones muy específicas”.
Esta puede ser otra pregunta estúpida, pero como solo atiendo a público finlandés, no veo ninguna razón para usar Cloudflare, así que solo lo conozco por su reputación.
Pero si su único beneficio es detener los ataques DDoS, y los ataques DDoS en su mayoría significan demasiadas llamadas realizadas por
rastreadores SEO inútiles
otros bots hechos por script kiddies
entonces, ¿por qué no usar Nginx delante de Discourse y detener los user agents conocidos allí? Cuando se combina con Fail2ban, eso reduciría la carga en algo así como un 90 % (seguro que es una estadística de Stetson, pero de todos modos es mucho).
Esta discusión es muy valiosa. Para un administrador de sitios web chino, ¿podría Flare significar si los usuarios chinos pueden intercambiar datos normalmente con el mundo exterior? Hice una prueba hace algún tiempo. Si no usas Orange Cloud y accedes a servidores en otros países desde China, la fluctuación de la red será muy seria. Lo malo es que administrar un foro en China está sujeto a una estricta censura. A pesar de que estaba administrando un foro no político, todavía sufrí. Debemos asumir que el servidor del sitio web está ubicado fuera de China. Por lo tanto, si creo un foro usando Discourse, tengo que considerar si puede usar Cloud Flare.
