Einrichtung von Let's Encrypt mit mehreren Domains / Weiterleitungen

[brahn]

NOTE: @pfaffman says: This page needs to be cleaned up. There is now a new ENV setting that will let you add more hostnames. In your app.yml under your DISCOURSE_HOSTNAME line (it can go many places but that one makes sense), add

 DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com

and early reports suggest that you’ll get valid certs for those domains and that accessing https://domain.com will properly redirect you to your DISCOURSE_HOSTNAME without a certificate error.

If you do that and it works for you, you might add another “me too!” post to the bottom. If you feel comfortable, you could also edit this first post with the instructions that you think would be most helpful.

---

This is to address the problem where you get certificate errors with any redirects or CNAME DNS entries which point to your actual installed Discourse (sub)domain.

If you do not have https configured already (you do if you have done a standard install recently) see Setting up Let’s Encrypt as your first step.

Legacy Method

The method below no longer reliably works as of August 2025

There are three patterns that need to be replaced. Enter your (sub)domain (and any additional subdomains preceded by -d ) and then add the following to your app.yml hooks section (towards the end of the file):

2025-04-23 @pfaffman changed the code because there’s a 3rd place it needs to be changed

  after_ssl:
    - replace:
        filename: /etc/runit/1.d/letsencrypt
        from: /-d =domain1= /
        to: "-d =domain1= -d =domain2= "
        global: true

This will allow you to have HTTPS configured for a second domain that will redirect to the correct one without certificate issues.

If you need to add multiple extra domains, you can enter something like this in the domain2 field: www.bananas.com -d forum.bananas.com

For example, if you want people who visit https://forum.example.com to be redirected to your forum at https://community.example.com without a certificate error, this is all you need.

[Rhod (Rodolfo)]

Danke, funktioniert dies, um „www.example.com“ auf „comunnity.example.com“ umzuleiten?
Oder wie kann ich das machen?
Ich habe Probleme mit meiner Domain www.example.com. Ich habe die DNS-Einstellungen so konfiguriert, dass sie auf comunnity.example.com umgeleitet werden, aber es funktioniert weder in Firefox noch in Chrome.

[JimPas]

Es gibt ein Redirect-Checker-Tool, um Ihre Weiterleitungen zu überprüfen.

[merefield (Robert)]

Ich habe damit ein wenig zu kämpfen. OK, viel.

Ich habe beschlossen, mit dem Hinzufügen eines CDN zu einer meiner Websites zu experimentieren.

Nachdem ich die Dokumentation gelesen hatte, erkannte ich, dass es für meine Website besser war, von ihrer aktuellen Apex-Domain auf eine Subdomain umzuziehen, um die von Fastly empfohlenen Kriterien (und die allgemeine Empfehlung dazu) zu erfüllen.

Also dachte ich: „Ach, das wird ein Kinderspiel, das habe ich schon mal gemacht …“. Oh ja?!
Die betreffende Website ist https://starzen.space.
Ich habe sie dieses Wochenende nach https://www.starzen.space verschoben, indem ich die Anleitung hier verwendet habe.
Alles lief gut, ABER natürlich muss ich immer noch die kleine Anzahl von Benutzern berücksichtigen, die ich bisher auf dieser Website gewonnen habe, also wollte ich eine Weiterleitung hinzufügen.
Nach meinem Verständnis muss ich dann auch den ursprünglichen Link mit einem Zertifikat ausstellen. Nach dieser Anleitung (die viel aufwendiger war?) habe ich dies zu app.yml hinzugefügt:

hooks:
  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d starzen.space --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
  after_web_config:
    - replace:
        filename: /etc/nginx/nginx.conf
        from: /sendfile.+on;/
        to: |
          server_names_hash_bucket_size 64;
          sendfile on;
    - file:
        path: /etc/nginx/conf.d/discourse_redirect_1.conf
        contents: |
          server {
            listen 80;
            listen 443 ssl;
            server_name starzen.space;
            return 301 $scheme://www.starzen.space$request_uri;
          }

Bei einem erneuten Build scheint alles gut zu laufen.

Wenn ich jedoch versuche, https://starzen.space über einen Browser aufzurufen, erhalte ich:

Und wenn ich curl verwende:

blah discourse % curl https://starzen.space
curl: (60) SSL: no alternative certificate subject name matches target host name 'starzen.space'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Ich bin mir ziemlich sicher, dass das Zertifikat schuld ist, denn wenn ich dasselbe im unsicheren Modus ausführe, erhalte ich:

blah discourse % curl -k https://starzen.space

301 Moved Permanently
301 Moved Permanently
nginx/1.21.6

was meiner Meinung nach das ist, was ich will.

Ich denke, die geänderte Skriptdatei ist korrekt, hier ist, was ich habe:

root@starship-enterprise:/etc/runit/1.d# cat letsencrypt
#!/bin/bash
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf

issue_cert() {
  LE_WORKING_DIR="${LETSENCRYPT_DIR}" /shared/letsencrypt/acme.sh --issue $2 -d www.starzen.space -d starzen.space --keylength $1 -w /var/www/discourse/public
}

cert_exists() {
  [[ "$(cd /shared/letsencrypt/www.starzen.space$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")"]]
}

########################################################
# RSA cert
########################################################
issue_cert "4096"

if ! cert_exists ""; then
  # Try to issue the cert again if something goes wrong
  issue_cert "4096" "--force"
fi

<SNIP>

Ich habe dies sogar von der Befehlszeile aus innerhalb des Containers ausgeführt, nachdem ich ALLE Zertifikatsdateien aus dem Zielverzeichnis in ein Backup-Verzeichnis verschoben hatte, damit der richtige Befehl für die doppelte Domain ausgeführt wird:

root@starship-enterprise:/etc/runit/1.d# ./letsencrypt
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[Sun 25 Sep 2022 05:50:04 PM UTC] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Sun 25 Sep 2022 05:50:04 PM UTC] Creating domain key
[Sun 25 Sep 2022 05:50:05 PM UTC] The domain key is here: /shared/letsencrypt/www.starzen.space/www.starzen.space.key
[Sun 25 Sep 2022 05:50:05 PM UTC] Multi domain='DNS:www.starzen.space,DNS:starzen.space'
[Sun 25 Sep 2022 05:50:05 PM UTC] Getting domain auth token for each domain
[Sun 25 Sep 2022 05:50:08 PM UTC] Getting webroot for domain='www.starzen.space'
[Sun 25 Sep 2022 05:50:08 PM UTC] Getting webroot for domain='starzen.space'
[Sun 25 Sep 2022 05:50:08 PM UTC] www.starzen.space is already verified, skip http-01.
[Sun 25 Sep 2022 05:50:08 PM UTC] Verifying: starzen.space
[Sun 25 Sep 2022 05:50:12 PM UTC] Pending
[Sun 25 Sep 2022 05:50:15 PM UTC] Success
[Sun 25 Sep 2022 05:50:15 PM UTC] Verify finished, start to sign.
[Sun 25 Sep 2022 05:50:15 PM UTC] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/590255196/128806215177'
[Sun 25 Sep 2022 05:50:16 PM UTC] Downloading cert.
[Sun 25 Sep 2022 05:50:16 PM UTC] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03ff6b1b76f8516165032c6c2e02205a529b'
[Sun 25 Sep 2022 05:50:17 PM UTC] Cert success.
-----BEGIN CERTIFICATE-----
Lotsofcrazytext
-----END CERTIFICATE-----
[Sun 25 Sep 2022 05:50:17 PM UTC] Your cert is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.cer
[Sun 25 Sep 2022 05:50:17 PM UTC] Your cert key is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.key
[Sun 25 Sep 2022 05:50:17 PM UTC] The intermediate CA cert is in  /shared/letsencrypt/www.starzen.space/ca.cer
[Sun 25 Sep 2022 05:50:17 PM UTC] And the full chain certs is there:  /shared/letsencrypt/www.starzen.space/fullchain.cer
[Sun 25 Sep 2022 05:50:17 PM UTC] Installing key to:/shared/ssl/www.starzen.space.key
[Sun 25 Sep 2022 05:50:17 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space.cer
[Sun 25 Sep 2022 05:50:17 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 579) 35281s
[Sun 25 Sep 2022 05:50:17 PM UTC] Reload success
[Sun 25 Sep 2022 05:50:18 PM UTC] Domains not changed.
[Sun 25 Sep 2022 05:50:18 PM UTC] Skip, Next renewal time is: Wed 23 Nov 2022 10:01:01 AM UTC
[Sun 25 Sep 2022 05:50:18 PM UTC] Add '--force' to force to renew.
[Sun 25 Sep 2022 05:50:18 PM UTC] Installing key to:/shared/ssl/www.starzen.space_ecc.key
[Sun 25 Sep 2022 05:50:18 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space_ecc.cer
[Sun 25 Sep 2022 05:50:18 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 579) 35282s
[Sun 25 Sep 2022 05:50:18 PM UTC] Reload success

Größtenteils ein voller Erfolg!!!, curl ist jetzt viel freundlicher und gibt mir die Weiterleitung:

blah discourse % curl https://starzen.space

301 Moved Permanently
301 Moved Permanently
nginx/1.21.6

Und https://starzen.space in Firefox & Chrome funktioniert jetzt und leitet zur richtigen Unterseite weiter, aber ich bekomme immer noch die gefürchtete Grafik des Verderbens in Safari, was ist los? Ich habe es sogar neu gestartet und die Caches für diese Website gelöscht:

Wenn ich mir das Zertifikat vom Browser aus ansehe, sehe ich:

[pfaffman (Jay Pfaffman)]

Ich wollte mir das schon genauer ansehen. Ich denke, es gibt jetzt zwei Stellen in der Let’s Encrypt-Vorlage, an denen die zusätzliche Domain eingetragen werden muss. Ich glaube nicht, dass Sie Änderungen am Nginx-Zeug vornehmen müssen, da es bereits eine 301-Weiterleitung für alles außer dem Hostnamen durchführt.

Sie müssen sich die Let’s Encrypt-Vorlage ansehen und prüfen, wo der Hostname eingetragen wird, und sicherstellen, dass Sie dies auch mit dem zusätzlichen Hostnamen tun.

[merefield (Robert)]

@pfaffman

Ich glaube nicht, dass du irgendwelche Änderungen am Nginx-Zeug vornehmen musst, da es bereits 301 auf alles außer dem Hostnamen umleitet.

Ja, danke, das habe ich der Vollständigkeit halber gemacht und es scheint noch keinen Schaden angerichtet zu haben, aber ich baue es gerne irgendwann ohne wieder auf.

@pfaffman

Schau dir die Let’s Encrypt-Vorlage an und sieh nach, wo sie den Hostnamen einfügt, und stelle sicher, dass du das auch mit dem zusätzlichen Hostnamen machst.

Es scheint zwei Sätze kryptografischer Dateien zu geben?:

root@starship-enterprise:/shared/letsencrypt# cd starzen.space
root@starship-enterprise:/shared/letsencrypt/starzen.space# ls
backup	ca.cer	fullchain.cer  starzen.space.cer  starzen.space.conf  starzen.space.csr  starzen.space.csr.conf  starzen.space.key
root@starship-enterprise:/shared/letsencrypt/starzen.space# cd ..
root@starship-enterprise:/shared/letsencrypt# cd www.starzen.space
root@starship-enterprise:/shared/letsencrypt/www.starzen.space# ls
backup	    ca.cer	   www.starzen.space.cer   www.starzen.space.csr       www.starzen.space.key
backup_two  fullchain.cer  www.starzen.space.conf  www.starzen.space.csr.conf
root@starship-enterprise:/shared/letsencrypt/www.starzen.space#

Ah, könnte es hier sein (und unten)

templates/web.letsencrypt.ssl.template.yml

Es enthält nur Informationen für den Hostnamen, nicht für die Apex?

[merefield (Robert)]

Nein, ich denke, das ist richtig? Es sollte ein Zertifikat geben, und es sollte sowohl für www. als auch für Apex funktionieren.

Dieses Tool schlägt vor, dass auf meinem öffentlichen Zertifikat nur eine Domain vorhanden ist (was das Problem verursachen würde?):

SSLCheck

[pfaffman (Jay Pfaffman)]

Sie müssen den Teil von Let’s Encrypt ändern, der das Zertifikat abruft. Es muss das einzelne Zertifikat für beide Domains angefordert werden. Diese Anweisungen funktionierten früher, aber ich glaube, etwas hat sich daran geändert, wie das Zertifikat angefordert wird. Wenn es das richtige Zertifikat erhält, funktioniert alles andere einfach.

[JimPas]

Wenn Sie certbot certificates ausführen, werden Ihr(e) Zertifikat(e) und die Domain(s), die es abdeckt, angezeigt. Wenn es sowohl den Apex als auch die www-Adresse nicht abdeckt, können Sie

1. Certbot erneut ausführen und ein Zertifikat sowohl für den Apex als auch für die www-Adresse erstellen lassen;

Wenn Sie sich für diese Option entscheiden, führen Sie certbot certificates aus, um den Namen des zu löschenden Zertifikats zu erhalten. Führen Sie certbot delete (Name des zu löschenden Zertifikats) aus. Sie sollten nur noch Ihr neues Zertifikat (mit Apex und www) haben.

oder (am einfachsten)

2. führen Sie certbot --expand -d existing.domain -d added.domain aus

Dadurch wird Ihr Zertifikat mit einem neuen Zertifikat aktualisiert, das die ursprüngliche Domain und die mit dem -d-Flag hinzugefügten Domains enthält.

[merefield (Robert)]

@JimPas

certbot-Zertifikate

Jim, certbot-Befehl nicht gefunden? Ist dies Teil der Standardinstallation und es gibt nur ein Pfadproblem?

[pfaffman (Jay Pfaffman)]

Ohne nachzusehen… Ich glaube, certbot ist das, was man normalerweise benutzt, aber innerhalb des Containers hat Discourse acme verwendet.

Und auch damit zusammenhängend, versuchst du das innerhalb oder außerhalb des Containers?

(Außerdem wird mein Tag immer voller und ich kann das vielleicht nicht mehr so sorgfältig prüfen, wie ich es ursprünglich dachte, aber es stand auf meiner Liste)

[merefield (Robert)]

Stimme zu … ein Weg, dies zu tun, ist meiner Meinung nach dieser?:

Wenn ich von einer beliebigen geeigneten Linux-Befehlszeile aus verwende

true | openssl s_client -connect www.starzen.space:443 2>/dev/null \
| openssl x509 -noout -text \
| perl -l -0777 -ne '@names=/\\bDNS:([^\\s,]+)/g; print join("\\n", sort @names);'

erhalte ich nur eine Domain und die Apex fehlt.

[pfaffman (Jay Pfaffman)]

Im Container finden Sie den Code, der das Zertifikat anfordert (und erneuert?) und sehen, dass er es für beide Domains anfordert.

[merefield (Robert)]

Ja, das ist der Fall, gemäß:

LE_WORKING_DIR="${LETSENCRYPT_DIR}" /shared/letsencrypt/acme.sh --issue $2 -d www.starzen.space -d starzen.space --keylength

Und das können Sie in der obigen Protokollausgabe sehen.

Es gibt jedoch einige andere Schritte zur Zertifikatsinstallation, die nur -d www.starzen.space enthalten, was ein Problem darstellen könnte? Obwohl, wenn dieses Zertifikat für beides erstellt wird, ist das vielleicht nicht das Problem …

[pfaffman (Jay Pfaffman)]

@merefield

Es gibt jedoch einige andere Schritte zur Installation von Zertifikaten, die nur -d www.starzen.space enthalten, was ein Problem darstellen könnte?

Das versuche ich die ganze Zeit zu sagen. Sie müssen diese anscheinend auch aktualisieren. Ich bin mir nicht sicher, warum es jetzt mehrere gibt, aber der OP muss mit Code aktualisiert werden, um all diese Schritte zu ändern. Oder das denke ich zumindest.

[merefield (Robert)]

Ja, ich werde das versuchen, zunächst manuell

[pfaffman (Jay Pfaffman)]

Gut. Das ist es, was ich tun wollte. Vielleicht habe ich Sie dazu verleitet.

[merefield (Robert)]

Es ist sinnvoll, es zu versuchen, nur dass ich den Container möglicherweise neu erstellen muss, um nano zu installieren …

[pfaffman (Jay Pfaffman)]

Nein!

 apt-get uodate;apt-get install nano

Das können Sie einfach innerhalb des Containers ausführen. Ich mache das ständig (außer dass ich vim benutze)

[merefield (Robert)]

Das hat leider nicht funktioniert:

root@starship-enterprise:/etc/runit/1.d# ./letsencrypt 
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
[Mon 26 Sep 2022 12:35:54 PM UTC] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon 26 Sep 2022 12:35:54 PM UTC] Creating domain key
[Mon 26 Sep 2022 12:35:56 PM UTC] The domain key is here: /shared/letsencrypt/www.starzen.space/www.starzen.space.key
[Mon 26 Sep 2022 12:35:56 PM UTC] Multi domain='DNS:www.starzen.space,DNS:starzen.space'
[Mon 26 Sep 2022 12:35:56 PM UTC] Getting domain auth token for each domain
[Mon 26 Sep 2022 12:35:59 PM UTC] Getting webroot for domain='www.starzen.space'
[Mon 26 Sep 2022 12:35:59 PM UTC] Getting webroot for domain='starzen.space'
[Mon 26 Sep 2022 12:35:59 PM UTC] www.starzen.space is already verified, skip http-01.
[Mon 26 Sep 2022 12:35:59 PM UTC] starzen.space is already verified, skip http-01.
[Mon 26 Sep 2022 12:36:00 PM UTC] Verify finished, start to sign.
[Mon 26 Sep 2022 12:36:00 PM UTC] Lets finalize the order.
[Mon 26 Sep 2022 12:36:00 PM UTC] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/590255196/129044627717'
[Mon 26 Sep 2022 12:36:01 PM UTC] Downloading cert.
[Mon 26 Sep 2022 12:36:01 PM UTC] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03ffc90cecd2f11f2ba386da2d501127aee5'
[Mon 26 Sep 2022 12:36:02 PM UTC] Cert success.
-----BEGIN CERTIFICATE-----
phewbigcert
-----END CERTIFICATE-----
[Mon 26 Sep 2022 12:36:02 PM UTC] Your cert is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] Your cert key is in  /shared/letsencrypt/www.starzen.space/www.starzen.space.key 
[Mon 26 Sep 2022 12:36:02 PM UTC] The intermediate CA cert is in  /shared/letsencrypt/www.starzen.space/ca.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] And the full chain certs is there:  /shared/letsencrypt/www.starzen.space/fullchain.cer 
[Mon 26 Sep 2022 12:36:02 PM UTC] Installing key to:/shared/ssl/www.starzen.space.key
[Mon 26 Sep 2022 12:36:02 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space.cer
[Mon 26 Sep 2022 12:36:02 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 2970) 329s
[Mon 26 Sep 2022 12:36:02 PM UTC] Reload success
[Mon 26 Sep 2022 12:36:03 PM UTC] Domains not changed.
[Mon 26 Sep 2022 12:36:03 PM UTC] Skip, Next renewal time is: Wed 23 Nov 2022 10:01:01 AM UTC
[Mon 26 Sep 2022 12:36:03 PM UTC] Add '--force' to force to renew.
[Mon 26 Sep 2022 12:36:04 PM UTC] Installing key to:/shared/ssl/www.starzen.space_ecc.key
[Mon 26 Sep 2022 12:36:04 PM UTC] Installing full chain to:/shared/ssl/www.starzen.space_ecc.cer
[Mon 26 Sep 2022 12:36:04 PM UTC] Run reload cmd: sv reload nginx
ok: run: nginx: (pid 2970) 331s
[Mon 26 Sep 2022 12:36:04 PM UTC] Reload success

Was immer noch ein Zertifikat mit einer einzelnen Domain zu exponieren scheint…

true | openssl s_client -connect www.starzen.space:443 2>/dev/null \
| openssl x509 -noout -text \
| perl -l -0777 -ne '@names=/\\bDNS:([^\\s,]+)/g; print join("\\n", sort @names);'
www.starzen.space