Discourse et Cloudflare

Oui, le défi HTTP-01 fonctionne en conjonction avec Cloudflare en mode « nuage orange ». Mais il ne fonctionne pas sur HTTPS, le défi HTTP-01 ne fonctionne que sur le port 80, et :

Beaucoup de personnes utilisant Cloudflare configurent Cloudflare pour rediriger automatiquement HTTP vers HTTPS, et cela rend le port 80 sur le serveur d’origine indisponible, et cela empêche les défis HTTP-01 de fonctionner.

Donc, si vous n’activez pas ces redirections, cela fonctionnera.

Donc, strictement parlant, c’est faux.
Let’s Encrypt échouera si Cloudflare est configuré pour rediriger le trafic sur le port 80 avant qu’il n’atteigne le serveur d’origine.

2 « J'aime »

Je suis d’accord, cependant, comme la sécurité informatique est plus présente que jamais et que les gens commencent à travailler davantage avec des produits Zero Trust, dont CF Tunnel fait partie, nous verrons et devrions voir une augmentation de l’utilisation de ce type de technologie, c’est pourquoi je l’ai mentionné.

Je pense que vous avez mal compris le fonctionnement du défi HTTP-01 de LE.
Il recherche le jeton que certbot ou une autre variante du client LE place, la plupart du temps, dans le sous-dossier .well-known du serveur web.
Mais il n’est pas codé en dur pour démarrer la requête sur le port 80, ignorer les redirections de code HTTP et échouer complètement s’il ne trouve pas le jeton.
Le défi HTTP-01 est capable de suivre les redirections HTTP (donc 301 et 302) et est donc capable de lire le dossier .well-known via le port 443 et HTTPS.
Et la raison pour laquelle cela fonctionne avec Cloudflare Universal SSL AVEC Redirection (et Cloudflare Tunnel) est que Cloudflare répond à la place du serveur web sur le port 80, redirige la requête vers le port 443, où LE peut lire le jeton et où la CA peut émettre le certificat.

Diagramme de haut niveau du flux :

Certbot démarre HTTP-01
→ POST la requête de certificat à la CA et place le jeton dans .well-known
→ La CA démarre GET pour le jeton sur le FQDN port 80
→ CF redirige vers le port 443 et sécurise la requête avec son certificat Universal SSL
→ La requête est transmise au serveur web lui-même (via CF Tunnel ou directement)
→ La CA est capable d’obtenir le jeton dans .well-known car le port 443 est capable de présenter le jeton de la même manière que le ferait HTTP et le port 80
→ La CA POST les données brutes du certificat et Certbot crée les fichiers

J’ai lancé un sujet en mars à la recherche de détails ou de guides plus récents sur la façon d’implémenter Cloudflare.

J’en cherche toujours un :slight_smile:

J’utilise Cloudfront comme CDN mais j’aimerais ajouter la protection DDoS qu’apporte Cloudflare. Nous sommes beaucoup sollicités :confused:

Je pense que je le comprends très bien. Vous avez raison, il peut être redirigé vers HTTPS, mais cela dépend des paramètres de Cloudflare et de la configuration du serveur Web pour que cela fonctionne ou non, car initialement, il n’y aura pas de certificat valide sur le serveur d’origine.

Oui, ils peuvent être redirigés vers un port différent, mais les défis HTTP-01 doivent toujours commencer sur le port 80.

Voir Challenge Types - Let's Encrypt

Le défi HTTP-01 ne peut être effectué que sur le port 80. Permettre aux clients de spécifier des ports arbitraires rendrait le défi moins sécurisé, et il n’est donc pas autorisé par la norme ACME.

2 « J'aime »

Je suis d’accord, j’ai juste souligné votre inexactitude selon laquelle cela ne fonctionnera jamais directement.


La citation de ma phrase que vous avez exécutée ici est assez malveillante car elle suggère une mauvaise circonstance de discussion et implique un autre sens. Ma phrase complète était

et la partie importante de ma phrase était la combinaison de “codé en dur pour démarrer la requête sur le port 80” ET “ignorer toute redirection HTTP” ET “échouer immédiatement”, puisque vous avez dit

et cela implique que la raison de l’échec du défi HTTP-01 est la redirection seule, ce qui n’est pas vrai.
De plus, à strictement parler, une redirection ne rend pas le port 80 “indisponible”.

Aucune malice n’est voulue ou intentionnelle.

Elle rend le port 80 du serveur d’origine indisponible pour tout le trafic dirigé vers le nom d’hôte.

Je n’aime pas le ton actuel de la conversation dans ce sujet, je vais donc le désactiver.

Mon opinion sur Cloudflare en combinaison avec Discourse peut se résumer ainsi : « de nombreuses personnes ne parviennent apparemment pas à le configurer correctement, donc en général, je déconseillerais de l’activer. Si vous souhaitez l’utiliser pour la protection DDoS, alors je recommanderais de l’activer avec des paramètres très spécifiques uniquement. »

6 « J'aime »

C’est une déclaration claire, merci.

3 « J'aime »

Ceci peut être une autre question stupide, mais comme je ne sers qu’un public finlandais, je ne vois aucune raison d’utiliser Cloudflare, donc je ne le connais que par sa réputation.

Mais si son seul avantage est d’arrêter les DDoS, et que les DDoS signifient principalement trop d’appels effectués par

  • des robots d’exploration SEO inutiles
  • d’autres bots créés par des script kiddies

alors pourquoi ne pas utiliser Nginx devant Discourse et arrêter les user agents connus là-bas ? Combiné avec Fail2ban, cela réduirait la charge d’environ 90 % (statistique de Stetson, bien sûr, mais beaucoup quand même).

Cette discussion est très précieuse. Pour un administrateur de site Web chinois, Flare peut-il signifier que les utilisateurs chinois peuvent normalement échanger des données avec le monde extérieur. J’ai fait un test il y a quelque temps. Si vous n’utilisez pas Orange Cloud et accédez à des serveurs dans d’autres pays depuis la Chine, le gigue réseau sera très grave. La chose diabolique est que l’exploitation d’un forum en Chine est soumise à une censure stricte. Même si je tenais un forum non politique, j’en ai quand même souffert. Nous devons supposer que le serveur du site Web est situé en dehors de la Chine. Donc, si je crée un forum en utilisant Discourse, je dois considérer s’il peut utiliser Cloud Flare.

1 « J'aime »