OAuth2 und Letsencrypt geraten aneinander

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?

Vielen Dank im Voraus.

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.

Dieses Problem wurde letzten August behoben, letsencrypt updates: renew location for .well-known, add support for … · discourse/discourse_docker@ae4887a · GitHub

1 „Gefällt mir“