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)
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?
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.
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.
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.