HTTPS-Unterstützung mit Let's Encrypt einrichten

[Discourse]

Dies ist eine Anleitung zum Aktivieren von HTTPS auf einer bestehenden Discourse-Installation mit Let’s Encrypt. Sie setzt eine vorherige Installation ohne aktiviertes HTTPS voraus.

Erforderliche Benutzerrolle: Systemadministrator

Diese Anleitung gilt nur für bestehende Installationen, bei denen HTTPS nicht aktiviert ist. Die Befolgung des offiziellen Einrichtungsleitfadens aktiviert HTTPS standardmäßig automatisch.

Sie möchten HTTPS für Ihr Discourse absolut kostenlos hinzufügen, dank unserer Freunde bei Let’s Encrypt?

Ist alles andere auf Ihrer Website für HTTPS bereit?

Bevor Sie beginnen, beachten Sie bitte, dass für eine ordnungsgemäße Funktion von HTTPS jede einzelne Ressource auf der Seite HTTPS-kompatibel sein muss. Berücksichtigen Sie Ihr CDN, Ihre Social-Login-Dienste, Ihre Logo-Dateien, alle Drittanbieter-JavaScript-Skripte, Bilder, Schriftarten oder CSS – diese alle müssen über HTTPS verfügbar sein!

Hinweis: ./discourse-setup aktiviert Let’s Encrypt. Ab März 2017 können Sie es erneut ausführen, mehrmals die Eingabetaste drücken und Ihre E-Mail-Adresse eingeben; das Skript enthält die erforderlichen Vorlagen und fügt Ihre E-Mail-Adresse wie erforderlich ein. Es sei denn, Sie sind ein erfahrener Systemadministrator und wissen aus einem bestimmten Grund, warum Sie dies nicht tun sollten, sollten Sie discourse-setup ausführen, anstatt weiterzulesen. (Wenn Sie Discourse vor sehr langer Zeit installiert haben, müssen Sie möglicherweise noch immer app.yml manuell bearbeiten.)

Hinweis: Wenn Ihr Discourse über einen Reverse-Proxy (z. B. Cloudflare) abgerufen wird, funktioniert diese Konfiguration nicht.

HTTPS mit Let’s Encrypt konfigurieren

1. app.yml bearbeiten

Greifen Sie auf die Konfigurationsdatei Ihres Discourse zu:

cd /var/discourse
nano containers/app.yml

• Fügen Sie die folgenden Vorlagen hinzu:

  templates:
    - "templates/web.template.yml"
    - "templates/web.ssl.template.yml"
    - "templates/web.letsencrypt.ssl.template.yml"
  

Ist Discourse die einzige Website auf Ihrem Server?

Wenn Sie bereits web.socketed.template.yml verwenden, weil Sie andere Websites über Port 80 auf demselben Server hosten, stoppen Sie sofort. Sie sollten einen Let’s Encrypt-Client auf dem Host-System verwenden; die Validierung schlägt fehl, da der verwendete Client nicht an die erforderlichen Sockets binden kann.

2. HTTPS-Ports freigeben

Stellen Sie sicher, dass die folgenden Ports für HTTPS-Datenverkehr freigegeben sind:

expose:
  - "80:80"
  - "443:443"

3. E-Mail-Adresse für Let’s Encrypt hinzufügen

Fügen Sie die E-Mail-Adresse für Let’s Encrypt-Benachrichtigungen ein:

env:
  LETSENCRYPT_ACCOUNT_EMAIL: 'ihre-email@beispiel.de'

4. Anwendung neu erstellen

Wenden Sie die Änderungen an, indem Sie den Container neu erstellen:

./launcher rebuild app

5. HTTPS validieren

Rufen Sie Ihre Website über https://ihre-domain.de auf. Bei Erfolg sehen Sie, dass Ihre Website mit HTTPS gesichert ist.

Überprüfen Sie Ihre Ressourcen:

• Stellen Sie sicher, dass Assets (z. B. Bilder, Skripte) über HTTPS geladen werden.
• Konfigurieren Sie Social-Login-Dienste und CDN bei Bedarf für HTTPS neu.
• Beheben Sie alle Warnungen in der Browserkonsole bezüglich unsicherer Assets.

Discourse aktiviert force_https automatisch nach einem Neustart mit einem gültigen HTTPS-Zertifikat.

Wie funktioniert es?

Die Vorlage verwendet GitHub - acmesh-official/acme.sh: A pure Unix shell script ACME client for SSL / TLS certificate automation · GitHub, was

das einfachste Shell-Skript für den kostenlosen Let’s Encrypt-Zertifikatsclient ist.

Einfach und leistungsstark, Sie benötigen nur 3 Minuten zum Erlernen.

Rein in Bash geschrieben, keine Abhängigkeiten zu Python, acme-tiny oder dem offiziellen Let’s Encrypt-Client. Nur ein Skript, um Ihre Zertifikate automatisch auszustellen und zu erneuern.

Wahrscheinlich das kleinste, einfachste und intelligenteste Shell-Skript, um automatisch kostenlose Zertifikate von Let’s Encrypt auszustellen und zu erneuern.

web.letsencrypt.ssl.template.yml fügt Ihrem Container ein Boot-Skript hinzu, das

1. Ein leichtgewichtiges Nginx startet, um ACME-Herausforderungen auf Port 80 zu bedienen, bevor das Haupt-nginx hochgefahren ist.
2. Sowohl ein RSA- (4096-Bit) als auch ein ECDSA- (ec-256) Let’s Encrypt-Zertifikat im Webroot-Modus mit /var/www/discourse/public als Verzeichnis ausstellt.
3. Die Zertifikate in das Verzeichnis /shared/ssl/ installiert, das nginx erwartet. Gleichzeitig richtet es einen Cron-Job für die automatische Zertifikatserneuerung ein. Dies erneuert Ihre Zertifikate automatisch. Wenn Zertifikate noch nicht abgelaufen sind, passiert nichts. Wenn ein Zertifikat abläuft, erhalten Sie eine E-Mail von Let’s Encrypt an die bei der Einrichtung angegebene E-Mail-Adresse.
4. Setzt force_https auf true, wenn gültige Zertifikate erhalten wurden.

Fehlerbehebung

Protokolle überprüfen

Wenn HTTPS nicht funktioniert, überprüfen Sie die Protokolle auf SSL- oder Let’s Encrypt-Fehler mit:

./launcher logs app

Zertifikatsdateien überprüfen

Stellen Sie sicher, dass Zertifikat- und Schlüsseldateien vorhanden sind, mit:

ls -l /var/discourse/shared/standalone/ssl

Sie sollten Dateien wie diese sehen:

• ihre-domain.de.cer (RSA)
• ihre-domain.de.key (RSA)
• ihre-domain.de_ecc.cer (ECDSA)
• ihre-domain.de_ecc.key (ECDSA)

Zertifikate manuell erneuern

Wenn die automatische Erneuerung fehlschlägt, können Sie Ihre Zertifikate manuell neu ausstellen:

./launcher enter app
sv stop nginx
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
LE_WORKING_DIR=/shared/letsencrypt DEBUG=1 /shared/letsencrypt/acme.sh --issue -d beispiel.de -k 4096 -w /var/www/discourse/public
LE_WORKING_DIR=/shared/letsencrypt /shared/letsencrypt/acme.sh --installcert -d beispiel.de --fullchainpath /shared/ssl/beispiel.de.cer --keypath /shared/ssl/beispiel.de.key --reloadcmd "sv reload nginx"
LE_WORKING_DIR=/shared/letsencrypt DEBUG=1 /shared/letsencrypt/acme.sh --issue -d beispiel.de --keylength ec-256 -w /var/www/discourse/public
LE_WORKING_DIR=/shared/letsencrypt /shared/letsencrypt/acme.sh --installcert --ecc -d beispiel.de --fullchainpath /shared/ssl/beispiel.de_ecc.cer --keypath /shared/ssl/beispiel.de_ecc.key --reloadcmd "sv reload nginx"
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf -s stop

Mit sauberen Zertifikaten neu erstellen

Entfernen Sie alte Zertifikatsdateien und erstellen Sie neu, um von vorne zu beginnen:

rm -rf /var/discourse/shared/standalone/ssl
rm -rf /var/discourse/shared/standalone/letsencrypt
./launcher rebuild app

Einschränkungen

Let’s Encrypt-Zertifikate validieren nur die Domain und Verschlüsselung. Sie bestätigen nicht den Besitz oder die Identität, was in einigen Browsern als Warnung angezeigt werden kann. Weitere Details finden Sie in der Let’s Encrypt-Community.

[RBoy]

Was ist der Unterschied zwischen den Zertifikaten im Ordner standalone/letsencrypt und den Ordnern standalone/ssl?

Im letsencrypt-Ordner sehe ich zwei Unterordner für die Website mit Zertifikaten, einen mit dem Sitename (RSA) und einen anderen mit dem Sitename_ecc (ECC).

Dann sehe ich einen weiteren ssl-Ordner, der ebenfalls .key- und .cer-Zertifikate mit denselben Namen wie die Zertifikate in den letsencrypt-Ordnern Sitename und Sitename_ecc zu enthalten scheint.

Die Zeitstempel aller Dateien im ssl-Ordner unterscheiden sich jedoch von den Zeitstempeln in den letsencrypt-Ordnern, und vor allem unterscheiden sich die Dateigrößen der .cer-Zertifikatsdateien im ssl-Ordner von den Dateigrößen der .cer-Dateien in den letsencrypt-Ordnern.

Meine Fragen sind also:

• Was ist der Unterschied zwischen den Dateien in den ssl- und letsencrypt-Ordnern?
• Welcher wird von Discourse verwendet?
• Wenn die Ordner im ssl-Ordner beschädigt/gelöscht werden, können sie durch die Dateien aus dem letsencrypt-Ordner ersetzt werden? (Dies ist wichtig, da ich in eine Situation geraten bin, in der Letsencrypt während der Wiederherstellung einer Website aufgrund übermäßiger Wiederherstellungen keine Ersatzzertifikate erhalten konnte, ich aber eine gültige Kopie funktionierender Zertifikate aus dem letsencrypt-Ordner aus einem Image-Backup hatte).

[sober]

@tgxworld

LE_WORKING_DIR=/shared/letsencrypt DEBUG=1 /shared/letsencrypt/acme.sh --issue -d example.com -k 4096 -w /var/www/discourse/public
LE_WORKING_DIR=/shared/letsencrypt /shared/letsencrypt/acme.sh --installcert -d example.com --fullchainpath /shared/ssl/example.com.cer --keypath /shared/ssl/example.com.key --reloadcmd "sv reload nginx"

@tgxworld
Kann LE_WORKING_DIR=/shared/letsencrypt DEBUG=1 /shared/letsencrypt/acme.sh --issue -d example.com -k 4096 -w /var/www/discourse/public in -d example.com -d www.example.com geändert werden, um SSL-Zertifikate für zwei Domains zu unterstützen?