Moment mal… ich glaube, ich habe es verstanden… Proxy deaktiviert und ohne die Cloudflare-Vorlage neu aufgebaut. Danach den Proxy wieder aktiviert, und ich kann jetzt WordPress und das Forum mit striktem SSL erreichen!
Du würdest sehr schnell eine Drosselung erhalten, wenn du die Cloudflare-Vorlage nicht verwenden würdest.
Discourse würde annehmen, dass sich viele Personen über dieselbe IP-Adresse (Cloudflare-Proxy) registrieren, und würde beginnen, sie zu drosseln.
Hmm… also besser noch einmal ohne die Letsencrypt-E-Mail, aber mit der Cloudflare-Vorlage… Weißt du, ob ich den Proxy aktiviert lassen soll, wenn ich mit der Cloudflare-Vorlage neu erstelle?
Vielen Dank für die ganze Hilfe… Ich bin eher ein kreativer Typ.
Es ist mein Registrar, nicht nur DNS… und ich kann mir die enorme Summe, die sie für die Nutzung eines anderen DNS verlangen, nicht leisten. Also, ups.
Die Discourse-Einrichtung erfordert mittlerweile seit geraumer Zeit keine E-Mail-Adresse mehr, um Zertifikate zu registrieren. Sofern Sie nicht die YAML-Konfiguration ändern, um SSL zu deaktivieren, wird standardmäßig immer HTTPS verwendet.
Die Nutzung von Cloudflare für DNS und das Aktivieren der orangen Wolke sind zwei völlig unterschiedliche Dinge. Im obigen Kontext bezieht sich die Nutzung von Cloudflare auf deren Proxy und Optimierungen, die in der Vergangenheit bereits einige seltsame Probleme verursacht haben. Ihr DNS ist hingegen in Ordnung, sogar gut.
Ihre Discourse-Installation muss nicht geändert werden; Sie haben HTTPS bereits funktionsfähig und alles dort ist in Ordnung. Wenn SSL funktioniert und die CloudFlare-Vorlage aktiviert ist, lassen Sie es unverändert.
Es scheint, als läge das Problem nun bei WordPress. Wie haben Sie das installiert? Ist es nur ein VPS, oder nutzen Sie irgendeine Art von WordPress-Hosting?
Dies ist eine sehr gängige Konfiguration, und ich bin mir ziemlich sicher, dass sich das leicht beheben lässt.
Das ist eine Very Bad Idea (sehr schlechte Idee). Sobald Discourse das Zertifikat von Let’s Encrypt registriert hat, werden die Erneuerungen erfolgreich sein, da sie über einen anderen Mechanismus erfolgen. Es besteht keine Notwendigkeit, TLS zwischen Server und CDN zu deaktivieren.
Warum dies angesichts des Vorstehenden tun? Abgesehen davon, dass Sie zusätzliche lokale Last durch die Verarbeitung von UFW-Regeln für gesamten Datenverkehr erzeugen, laufen Sie Gefahr, dass Ihre Regeln veralten – ein schneller Weg zu einer Reihe von Netzwerkfehlern. Cloudflare bringt regelmäßig neue IP-Bereiche online; das Erste, was Sie davon hören, wird sein, dass Ihre Nutzer nicht mehr auf die Seite zugreifen können. Lassen Sie das Zertifikat registrieren, und wenn Sie Cloudflare nutzen möchten, passen Sie einfach eine Page Rule entsprechend an.
Ich verwende Cloudflare im DNS-only-Modus, das ist ganz einfach. Klicke einfach im DNS-Steuerungsbereich auf die “orange Wolke” und schalte sie aus, sodass die Wolke stattdessen grau ist. Das ist alles, was du tun musst.
Das funktioniert nicht mehr wie früher. Wenn du Let’s Encrypt nicht verwenden möchtest, musst du es manuell konfigurieren, anstatt discourse-setup zu verwenden.
Welches Zertifikat würde Discourse erhalten, falls keine LE-E-Mail-Adresse vorhanden ist? Ein selbstsigniertes Zertifikat oder eines, das mit einer beliebigen E-Mail-Adresse ausgestellt wurde?
In beiden Fällen sollte es mit Cloudflare SSL weiterhin einwandfrei funktionieren, da Cloudflare in der Konfiguration „Full SSL“ und höher Hosts mit gültigen Zertifikaten zulässt.
Du musst den Quellcode prüfen, da ich mich nicht genau erinnere. Ich glaube, es wird die Administrator-E-Mail verwendet. Wenn die Prüfung, ob der Server auf Port 443 erreichbar ist, fehlschlägt, wird die Installation abgelehnt.
Ich kann hier absolut falsch liegen, aber laut diesem 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 to skip"
else
local letsencrypt_status="Enter 'OFF' to disable."
fi
scheint die Standardkonfigurationsprüfung eine Option zu bieten, “off” einzugeben, um Let’s Encrypt zu deaktivieren? Vielleicht liege ich völlig falsch und schaue an der völlig falschen Stelle?
Let’s Encrypt zu deaktivieren ist keine Lösung.
Bei einer Standardinstallation ist es nicht so. Bei einer erweiterten Installation (z. B. bei Verwendung eines Reverse-Proxys) ist es jedoch definitiv eine Antwort.
Könntest du das bitte näher erläutern?
Es ist einfach, das Zertifikatsszenario zum Laufen zu bringen. Selbst wenn du einen zweiten Webserver auf demselben Server betreibst und lokal proxyest, ist es einfach, das Zertifikat funktionsfähig zu machen. Warum solltest du es also nicht tun?
Warum sollte ich mehrere Zertifikate anfordern? Wenn ich einfach ein (einheitliches) Zertifikat von Let’s Encrypt über den Reverse-Proxy (z. B. Nginx/Caddy) anfordern kann, warum möchte ich dann ein zweites Zertifikat innerhalb des Discourse-Containers haben, wenn es ohnehin von nichts verwendet wird?
Ich denke, die allgemeine Antwort lautet, die Proxy-Komplexität, wenn möglich, ganz zu vermeiden 
Doch sobald man über die Standardkonfiguration mit ein oder zwei Containern hinausgeht, ist dies unvermeidlich.
Dein Forum muss wirklich ziemlich groß werden, um einen Proxy wie den von Cloudflare zu benötigen. Das ist etwas, das du in Betracht ziehen solltest, wenn dein Forum an seine Grenzen stößt. Es sei denn, du migrierst ein großes Forum zu Discourse – niemand, der Discourse installiert, sollte sich darüber Gedanken machen.
Ich stimme dem wirklich nicht zu, HTTPS richtig einzurichten ist einfach. In diesem Fall hostet der Nutzer zwei Seiten auf zwei verschiedenen Servern unter einer einzigen Domain.
Es gibt keinen technischen Grund, warum beide Seiten nicht unabhängig davon, ob CloudFlare aktiviert ist, über HTTPS ausgeliefert werden können. Sobald man die von Let’s Encrypt verwendete Registrierungsmethode und die Konfiguration von CloudFlare für Discourse versteht, ist das einfach zu bewerkstelligen. CloudFlare verfügt über einen vollständigen HTTPS-Modus, der genau für solche Szenarien gedacht ist. TLS vom Server zum CloudFlare-Netzwerk, TLS vom CloudFlare-Netzwerk zu den Clients, dazwischen entschlüsselt, damit CloudFlare cachen und „optimieren“ kann – wobei wir bei Discourse wissen, dass dieser letzte Teil nicht so gut funktioniert.
Vor allem das, obwohl es definitiv von Vorteil ist, eine Page Rule für das Cachen von /uploads/ zu konfigurieren – das wird eine Weile die Belastung verringern und einem VPS der unteren Preisklasse etwas länger eine gute Leistung ermöglichen.