Discourse-Zertifikat abgelaufen

[RBoy]

Fortsetzung des Gesprächs von hier:

Letsencrypt certificate failure to renew

I think it’s been years since I’ve seen a let’s encrypt certificate fail to renew, but I’ve had three sites in the past week or two that have stale certificates. A rebuild fixes it and I have heretofore failed to look for clues in the logs. Next time I’ll do a bit more to diagnose the problem before fixing it for the site.

Das erste Mal überhaupt, dass ich von Redsift eine Erinnerung erhalten habe, dass meine Zertifikate in einer Woche ablaufen. Normalerweise erneuert Discourse die Zertifikate rechtzeitig. Dieses Mal nicht, bevor ich mit einem Rebuild beginne (was das Problem lösen soll), @Falco gibt es etwas, das ich überprüfen und hier posten soll, um der Ursache auf den Grund zu gehen, warum die Zertifikate nicht erneuert wurden?
Das Stammzertifikat ist ISRGX1 und hier sind die Informationen zum ablaufenden Zertifikat:

Gemeinsamer Name (CN)	E6
Organisation (O)	Let’s Encrypt
Organisationseinheit (OU)	Nicht Teil des Zertifikats
Ausgestellt am	Mittwoch, 16. Juli 2025 um 19:36:45 Uhr
Läuft ab am	Dienstag, 14. Oktober 2025 um 19:36:44 Uhr

Der aktuelle Build ist 3.6.0.beta1-dev (7ee52c8f85)

[pfaffman (Jay Pfaffman)]

Es gab eine Zeit, in der der Endpunkt, den Let’s Encrypt benötigte, umgeleitet wurde. Das ist behoben, wenn Sie neu erstellen.

[Dannii]

Wie lange nach dem Update sollte das Zertifikat erneuert werden?

[featheredtoast (Jeff Wong)]

Wenn ich mich recht erinnere, sind die Zertifikate 3 Monate gültig und sie werden nun versuchen, sie vorher automatisch zu erneuern.

[Dannii]

Ja, ich weiß, wie es funktionieren soll.

Aber es ist über einen Tag her, seit ich die Forensoftware aktualisiert habe, und das Zertifikat scheint noch nicht aktualisiert worden zu sein. Es läuft in 5 Tagen ab, daher muss es bald erneuert werden.

Ich bin auf dem Discouse Stable Branch, falls das einen Unterschied macht. Ist es möglich, dass der Endpunkt-Fix nicht zurückportiert wurde?

[RBoy]

Für mich hat sich das Zertifikat nach dem Neuerstellen sofort aktualisiert.

[Dannii]

Haben Sie über das Web oder über die Befehlszeile neu aufgebaut?

[Canapin (Coin-coin le Canapin)]

Ja, die Erklärung war hier:

Let's Encrypt certificate doesn't automatically renew, but rebuilding does trigger the renewal

I recently worked on the le cert renewal. It is the http to https redirect - acme does not handle being told to redirect well at all and by default attempts to connect on the same protocol (http) as it did when it was setup initially Recent updates to the let’s encrypt template should fix these renewals going forward.

[Dannii]

Mein Forum hat endlich sein Zertifikat aktualisiert, nachdem ich einen Kommandozeilen-Neustart durchgeführt habe.

[lessLost (Michael)]

Wir haben die gleiche Erfahrung gemacht, dass SSL nicht erneuert wurde.

Es wäre großartig, wenn jemand überprüfen könnte, ob web.ssl.template auf discourse-docker korrekt funktioniert. Es schien mir, dass Port 80 keine /.well-known/-URLs bediente, die von Let’s Encrypt verwendet werden. Alle URLs wurden zu SSL weitergeleitet, einschließlich Testdateien, die ich manuell in /var/www/discourse/public/.well-known/ platziert hatte. Ich musste /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf direkt im App-Container bearbeiten.

Vielleicht begann dies nach Commit ae4887a von discourse-docker?

[pfaffman (Jay Pfaffman)]

Es gab einen weiteren Fehler auf der bekannten Route in jüngster Zeit.

Wann haben Sie das letzte Mal einen Rebuild durchgeführt?

[giuseppe.lanzi]

Bei mir auch. Ich habe keine Warnung über den Ablauf des Zertifikats erhalten. Die Eingabe des Servers und der Start eines Rebuilds /var/discourse % ./launcher rebuild hat das Problem behoben.

[lessLost (Michael)]

Bei meinen Tests auf einer Vanilla-Nginx-Installation (1.18.0, aber ich denke, es ist dasselbe für 1.26.3) überschreibt eine Nginx-Konfigurationszeile return 301 https://thehostname$request_uri; außerhalb eines Standorts vollständig jeden früheren location-Block davor, anstatt ein Catch-all zu sein. Ich glaube, /.well-known/ wird einfach nicht über Port 80 bedient, es sei denn, der 301-Redirect ist speziell für einen anderen Standort wie / am Ende des Serverblocks. Könnte das dasselbe Problem sein wie dieser Stackoverflow-Post?

Ich bin froh, dass der Wiederaufbau funktioniert, aber da das Zertifikat für mich bereits erneuert wurde, konnte ich nicht bestätigen, dass ein Wiederaufbau es den Let’s Encrypt-Validierungsservern ermöglichen würde, dorthin zu gelangen, wenn ein Zertifikat abgelaufen wäre. Vielleicht löst ein Wiederaufbau die Zertifikatserneuerung aus, bevor diese Vorlagenzeile vorhanden ist oder ähnlich, anstatt die Vorlagen zu korrigieren, aber ich kann nicht bestätigen, ob das der Grund ist, warum der Wiederaufbau die Erneuerung zum Laufen bringt.

[pfaffman (Jay Pfaffman)]

Wenn Sie denken, dass dies ein Discourse ist, sollten Sie vielleicht auf dem GitHub-Commit antworten oder einen neuen großen Bericht eröffnen.

[cedric_chin]

@lessLost

Bei meinen Tests auf einer Vanilla-Nginx-Installation (1.18.0, aber ich denke, es ist dasselbe für 1.26.3) überschreibt eine Nginx-Konfigurationszeile return 301 https://thehostname$request_uri; außerhalb eines location jeglichen früheren location-Block davor, anstatt als Auffangblock zu dienen. Ich glaube, /.well-known/ wird einfach nicht auf Port 80 bedient, es sei denn, der 301-Redirect ist speziell für einen anderen Ort wie / am Ende des Serverblocks. Könnte das dasselbe Problem sein wie in diesem Stackoverflow-Beitrag?

Ich kann bestätigen, dass die Let’s Encrypt-Erneuerung fehlschlägt. Ich betreibe seit Jahren eine selbst gehostete Discourse-Installation, und sehr seltsamerweise ist die Erneuerung bei mir in den letzten zwei Monaten zweimal hintereinander fehlgeschlagen. Das zweite Mal war heute Morgen, und deshalb habe ich angefangen zu recherchieren.

Ich habe es auf die folgenden zwei Commits zurückgeführt:

Use Nginx config outlets in templates

Und die relevante verlinkte Zeile:

FEATURE: Move letsencrypt scripts to work on boot (#977)

Ich denke, es gibt zwei Probleme.

Erstens wird return 301 https://${DISCOURSE_HOSTNAME}$request_uri; zu return 301 https://<MEIN SERVERNAME> ohne ein $request_uri am Ende. Ich habe dies auf meiner selbst gehosteten Installation und auch auf der eines Freundes, die in der letzten Woche eingerichtet wurde, überprüft. Ich verstehe nicht, wie die Discourse-Vorlage funktioniert, daher weiß ich nicht, warum es weggelassen wird.

Zweitens, wie @lessLost erwähnt hat, befindet sich der 301-Redirect außerhalb des location-Blocks. Ich glaube, ein Redirect auf Server-Ebene überschreibt alle location-Blöcke. LetsEncrypt verwendet HTTP für Erneuerungen. Jeder Versuch, curl -I http://DEINE_DOMAIN/.well-known/acme-challenge/test auszuführen, gibt jedoch einen 301 zu HTTPS zurück, anstatt eines 404 (was das erwartete Verhalten ist; wir wollen einen 404 und keinen 301).

Ich habe dies manuell auf meiner selbst gehosteten Installation behoben, aber ich erwarte, dass jedes Update meine Änderungen überschreibt. Leider verstehe ich die Vorlagen nicht gut genug, um einen Pull-Request einzureichen, @pfaffman – sonst würde ich das auch tun.

Bearbeitet, um hinzuzufügen:

Ich glaube, das ist falsch –

Let's Encrypt certificate doesn't automatically renew, but rebuilding does trigger the renewal

I recently worked on the le cert renewal. It is the http to https redirect - acme does not handle being told to redirect well at all and by default attempts to connect on the same protocol (http) as it did when it was setup initially Recent updates to the let’s encrypt template should fix these renewals going forward.

Ich bin mir ziemlich sicher, dass LetsEncrypt standardmäßig HTTP verwendet (aus offensichtlichen Gründen, wenn das Zertifikat abgelaufen ist, kann es nicht erneuert werden!). Aber das Platzieren des 301 auf Serverblock-Ebene erzwingt, dass alle Anfragen zu HTTPS umgeleitet werden, was nicht mit dieser Erneuerungsstrategie übereinstimmt.

[pfaffman (Jay Pfaffman)]

Wann haben Sie zuletzt neu aufgebaut?

[cedric_chin]

Heute Morgen, ungefähr 10 Minuten nachdem ich aufgewacht war, habe ich mein Forum besucht und festgestellt, dass das Zertifikat schon wieder abgelaufen war. (War es nicht das Neuerstellen, das es das letzte Mal erneuert hat, als es mir abgelaufen ist – vor ungefähr 3 Monaten?)

[pfaffman (Jay Pfaffman)]

@cedric_chin

(Neuerstellung hat es das letzte Mal behoben, als es bei mir abgelaufen ist – vor ungefähr 3 Monaten?)

Ich denke, sie haben seitdem Änderungen vorgenommen, die dieses Problem behoben haben, aber da es 3 Monate dauert, um es herauszufinden, ist das Urteil noch nicht gefallen. Sie könnten sich eine Erinnerung ein paar Wochen vor Ablauf des aktuellen Zertifikats einrichten.

[cedric_chin]

Das ist nicht wahr.

1. Die Links, die ich im obigen Kommentar angehängt habe, stammten von einem git blame. Hier ist die neueste Version der Datei (relevante Zeile verlinkt): discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub
2. Die neue Site-Installation meines Freundes war von vor einer Woche. Zeile 37 der obigen Vorlage lautet: return 301 https://${DISCOURSE_HOSTNAME}$request_uri;, aber im Discourse Docker Container liest sowohl ihre (als auch meine) /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf return 301 https://<your_discourse_site>;. Beachten Sie, dass $request_uri entfernt wird. Etwas bewirkt, dass dies verschwindet! (Ich weiß nicht was).
3. Ich habe heute Morgen eine simulierte erzwungene Erneuerung als Teil meiner Untersuchung durchgeführt. Sie ist fehlgeschlagen. Ich habe dann /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf geändert. Sie war erfolgreich!

Das ist eigentlich in Ordnung; ich werde 20-redirect-http-to-https.conf einfach jedes Mal manuell bearbeiten, wenn ich Discourse aktualisiere. Für diejenigen, die auf diesen Kommentar stoßen, lautet der auszuführende Befehl:

cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
  listen 80;
  listen [::]:80;

  location ~ /.well-known {
    root /var/www/discourse/public;
    allow all;
  }

  location / {
    return 301 https://<DEINE_FORUM_ADRESSE>$request_uri;
  }
}
EOF

Ich bin mir nicht ganz sicher, was dieses Scheitern verursacht, aber ich weiß, dass die Änderung der obigen Konfiguration es behebt. Aber ich habe auch Benachrichtigungen so modifiziert, dass Let’s Encrypt-Erneuerungen nicht mehr stillschweigend fehlschlagen – damit ich eine gewisse Vorwarnung habe. Dachte nur, Sie würden es wissen wollen!

[nat (Natalie T)]

Danke für den Bericht, ich denke, das ist echt.

(zu Info @featheredtoast)