Ich betreibe einen Discourse Docker-Container unter Ubuntu (erstellt aus einer DO-Vorlage) mit aktiviertem „Custom OAuth2“. Es funktioniert sehr gut, außer dass die Aktualisierung seines Letsencrypt-Zertifikats fehlschlägt.
Bei der Fehlersuche konnte ich in den Protokollen sehen, dass das Update-Skript von Cron ausgeführt wird, die Herausforderung jedoch abgelehnt wird, da Discource den Challenge-Callback an den OAuth2 IDP weiterleitet.
Hier ist das (redigierte) Protokoll:
\[Wed Jan 28 12:40:32 PM UTC 2026\] Erneuerung: ‚community.site‘
\[Wed Jan 28 12:40:32 PM UTC 2026\] Erneuerung mit Le_API=https://acme-v02.api.letsencrypt.org/directory
\[Wed Jan 28 12:40:33 PM UTC 2026\] CA wird verwendet: https://acme-v02.api.letsencrypt.org/directory
\[Wed Jan 28 12:40:33 PM UTC 2026\] Einzeldomäne=‚community.site‘
\[Wed Jan 28 12:40:35 PM UTC 2026\] Webroot für Domäne abrufen=‚community.site‘
\[Wed Jan 28 12:40:35 PM UTC 2026\] Verifizierung: community.site
\[Wed Jan 28 12:40:36 PM UTC 2026\] Ausstehend. Die CA verarbeitet Ihre Bestellung, bitte warten Sie. (1/30)
\[Wed Jan 28 12:40:40 PM UTC 2026\] community.site: Ungültiger Status. Details zum Verifizierungsfehler: 1.2.3.4: Ungültige Antwort von https://oauth.site/authorize?client_id=xxx
\[Wed Jan 28 12:40:40 PM UTC 2026\] Bitte überprüfen Sie die Protokolldatei für weitere Details: /shared/letsencrypt/acme.sh.log
\[Wed Jan 28 12:40:40 PM UTC 2026\] Fehler beim Erneuern von community.site.
Das erneute Erstellen der Anwendung behebt das Problem für die nächsten 3 Monate, aber ich würde es gerne richtig beheben. Irgendwelche Vorschläge?
Ich sehe hier nichts Offensichtliches, aber ehrlich gesagt würde ich das Setup einfach hinter einen Reverse-Proxy setzen, dort SSL beenden und stattdessen die DNS-Validierung verwenden. (Das ist nur ein Workaround, keine Lösung, da das Problem unbekannt ist)
Weitere Informationen zum Problem:
Ich sehe die eingehende acme-challenge-Anfrage an http://community.site/.well-known/…
Sie wird auf https://community.site/ umgeleitet und dann auf /oauth_basic umgeleitet. Die zweite Weiterleitung ist absolut erwartet, aber nicht die erste.
Die eingehende Challenge-Anfrage erscheint in access.log, access.letsencrypt.log ist leer
Ich habe eine Datei /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf gefunden, die anscheinend immer 301 https://community.site für jede Anfrage an Port 80 zurückgibt.
Interessant, ich habe die App am 26. November neu erstellt, daher würde ich erwarten, dass der Fix bis dahin enthalten ist…
Auf jeden Fall vielen Dank an alle für die Hilfe. Lassen Sie uns das Thema schließen und hoffen, dass das Problem nach dem nächsten Rebuild nicht wieder auftritt.
Ah, ich sehe, da war noch mehr dahinter. Sie können darüber hier bis zum Ende dieses Themas lesen und werden dann sehen, dass es am 22. Dezember noch eine weitere Korrektur gab. Das erklärt also, warum Sie darauf gestoßen sind.
Ich habe mir den Commit angesehen, ich habe es installiert. Aber ich glaube, da ist ein Fehler drin.
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
sollte sein return 301 https://${DISCOURSE_HOSTNAME}\\$request_uri;
Korrigieren Sie mich bitte, wenn ich falsch liege.
