Attends… je crois que j’ai compris… j’ai désactivé le proxy et reconstruit sans le modèle Cloudflare. J’ai réactivé le proxy ensuite et je peux accéder à WordPress et au forum avec SSL strict !
Vous seriez très facilement limité en taux si vous choisissiez de ne pas utiliser le modèle Cloudflare…
Discourse pensera que de nombreuses personnes s’enregistrent via la même adresse IP (proxy Cloudflare) et commencera à les limiter en taux.
Hmm… alors mieux vaut recommencer sans l’e-mail letsencrypt mais avec le modèle cloudflare… sais-tu si je dois laisser le proxy activé lorsque je reconstruis avec le modèle cloudflare ?
Merci beaucoup pour toute l’aide… je suis vraiment plus du côté créatif.
C’est mon registraire, pas seulement DNS… et je ne peux pas me permettre de payer la somme énorme qu’ils exigent pour que j’utilise un autre DNS. Alors, oups.
La configuration de Discourse ne nécessite plus d’adresse e-mail pour l’inscription des certificats, et ce depuis un certain temps. Sauf si vous modifiez le fichier YAML pour désactiver SSL, le protocole HTTPS sera toujours activé par défaut.
Utiliser Cloudflare pour DNS et activer le nuage orange sont deux choses totalement différentes. Dans le contexte ci-dessus, l’utilisation de Cloudflare fait référence à leur proxy et à leurs optimisations, qui ont déjà causé pas mal de problèmes par le passé. Leur service DNS, en revanche, est excellent.
Votre installation Discourse n’a pas besoin d’être modifiée, HTTPS fonctionne et tout est en ordre pour le moment. Si SSL fonctionne et que le modèle CloudFlare est activé, ne touchez à rien.
Il semble que le problème se situe maintenant au niveau de WordPress. Comment l’avez-vous installé ? Est-ce simplement un VPS, ou utilisez-vous un hébergeur WordPress d’un certain type ?
C’est une configuration très courante, je suis assez confiant qu’il s’agit d’une correction facile.
C’est une Très Mauvaise Idée. Une fois que Discourse a enregistré le certificat auprès de Let’s Encrypt, les renouvellements réussiront car ils s’effectuent via un mécanisme différent. Il n’y a pas besoin de désactiver TLS entre le serveur et le CDN.
Pourquoi faire cela compte tenu de ce qui précède ? Outre le fait de créer une charge supplémentaire de traitement local des règles UFW pour tout le trafic, vous prenez simplement le risque que vos règles deviennent obsolètes, ce qui est un moyen rapide de provoquer de nombreuses erreurs réseau. Cloudflare met régulièrement de nouvelles plages d’adresses IP en ligne ; la première chose dont vous entendrez parler sera l’impossibilité pour vos utilisateurs d’accéder au site. Laissez le certificat s’enregistrer, et si vous souhaitez utiliser CloudFlare, ajustez simplement une règle de page en conséquence.
J’utilise Cloudflare en mode DNS uniquement, c’est très simple. Cliquez simplement pour désactiver le « nuage orange » dans votre panneau de contrôle DNS, de sorte que le nuage devienne gris. C’est tout ce qu’il faut faire.
Cela ne fonctionne plus comme avant. Si vous ne souhaitez pas utiliser Let’s Encrypt, vous devez le configurer manuellement plutôt qu’avec discourse-setup.
Donc, quel certificat Discourse obtiendrait-il en l’absence d’une adresse e-mail Let’s Encrypt ? Un certificat auto-signé ou un certificat émis avec une adresse e-mail arbitraire ?
Dans les deux cas, cela devrait fonctionner sans problème avec SSL Cloudflare, car ils autorisent les hôtes disposant d’un certificat valide dans leur configuration SSL complet et au-dessus.
Vous devrez vérifier le code source, car je ne m’en souviens plus exactement. Je pense qu’il utilise l’adresse e-mail de l’administrateur. Si la vérification de la disponibilité du serveur sur le port 443 échoue, l’installation sera refusée.
Je peux avoir tout à fait tort, mais selon ce code :
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER pour ignorer"
else
local letsencrypt_status="Saisissez 'OFF' pour désactiver."
fi
il semble que la vérification de la configuration par défaut devrait offrir la possibilité de saisir “off” pour désactiver Let’s Encrypt ? Peut-être que j’ai tout à fait tort et que je regarde au mauvais endroit ?
Désactiver Let’s Encrypt n’est pas la solution.
Dans une installation standard, ce n’est pas le cas. Dans une installation avancée (par exemple, quelqu’un utilisant un proxy inverse), c’est tout à fait une réponse.
Pourriez-vous préciser pourquoi ?
Il est facile de faire fonctionner le scénario avec un certificat. Même si vous exploitez un deuxième serveur web sur le même serveur et que vous effectuez une mise en proxy localement, il est simple de faire fonctionner le certificat. Alors, pourquoi ne pas le faire ?
Pourquoi demander plusieurs certificats ?
Puisque je peux simplement demander un seul certificat (unifié) à Let’s Encrypt via le proxy inverse (par exemple nginx ou Caddy), pourquoi voudrais-je un deuxième certificat à l’intérieur du conteneur Discourse, alors qu’il ne sera utilisé par rien ?
Je pense que la réponse générale est d’éviter totalement la complexité du proxy, si possible 
Mais cela devient inévitable dès que l’on envisage un déploiement allant au-delà de la configuration standard d’un ou deux conteneurs.
Votre forum doit devenir vraiment très grand pour avoir besoin d’un proxy comme celui de Cloudflare. C’est quelque chose à envisager lorsque votre forum commence à être submergé. Sauf si vous migrez un grand forum vers Discourse, personne qui installe Discourse ne devrait y penser.
Je ne suis vraiment pas d’accord, mettre HTTPS en place correctement est simple. Dans ce cas, l’utilisateur a deux sites sur deux serveurs différents sous un même domaine.
Il n’y a aucune raison technique pour que les deux sites ne puissent pas être servis en HTTPS, que CloudFlare soit activé ou non. C’est facile à faire une fois que l’on comprend la méthode d’inscription utilisée par Let’s Encrypt et comment configurer CloudFlare pour Discourse. CloudFlare propose un mode HTTPS complet, conçu précisément pour ce scénario : TLS du serveur vers leur réseau, TLS de leur réseau vers les clients, avec déchiffrement intermédiaire afin qu’ils puissent mettre en cache et « optimiser », bien que nous sachions que, pour Discourse, cette dernière partie ne fonctionne pas très bien.
C’est surtout cela, bien qu’il y ait certainement un avantage à avoir une règle de page pour mettre en cache /uploads/ — cela aidera à soulager la charge pendant un certain temps et permettra à un VPS moins puissant de tenir un peu plus longtemps.