Ho un container Docker di Discourse in esecuzione su Ubuntu (creato dal modello DO) con “Custom OAuth2” abilitato. Funziona molto bene, tranne per il fatto che non riesce ad aggiornare il suo certificato Letsencrypt.
Rintracciando il problema, vedo dai log che lo script di aggiornamento viene eseguito da Cron, ma la verifica viene rifiutata poiché Discource reindirizza il callback di verifica all’Identity Provider (IDP) OAuth2.
Ecco il log (redatto):
\[Wed Jan 28 12:40:32 PM UTC 2026\] Renewing: ‘community.site’
\[Wed Jan 28 12:40:32 PM UTC 2026\] Renewing using Le_API=https://acme-v02.api.letsencrypt.org/directory
\[Wed Jan 28 12:40:33 PM UTC 2026\] Using CA: https://acme-v02.api.letsencrypt.org/directory
\[Wed Jan 28 12:40:33 PM UTC 2026\] Single domain=‘community.site’
\[Wed Jan 28 12:40:35 PM UTC 2026\] Getting webroot for domain=‘community.site’
\[Wed Jan 28 12:40:35 PM UTC 2026\] Verifying: community.site
\[Wed Jan 28 12:40:36 PM UTC 2026\] Pending. The CA is processing your order, please wait. (1/30)
\[Wed Jan 28 12:40:40 PM UTC 2026\] community.site: Invalid status. Verification error details: 1.2.3.4: Invalid response from https://oauth.site/authorize?client_id=xxx
\[Wed Jan 28 12:40:40 PM UTC 2026\] Please check log file for more details: /shared/letsencrypt/acme.sh.log
\[Wed Jan 28 12:40:40 PM UTC 2026\] Error renewing community.site.
La ricostruzione dell’app risolve il problema per i prossimi 3 mesi, ma vorrei risolverlo correttamente. Qualche suggerimento?
Non sono sicuro di vedere qualcosa di ovvio qui, ma onestamente metterei la configurazione dietro un proxy inverso e terminerei la ssl lì, quindi userei la validazione DNS invece. (questa è solo una soluzione temporanea, non una soluzione perché il problema è sconosciuto)
Maggiori informazioni sul problema:
Vedo la richiesta in arrivo di acme-challenge a http://community.site/.well-known/…
Viene reindirizzata a https://community.site/ e poi reindirizzata a /oauth_basic. Il secondo reindirizzamento è del tutto previsto, ma non il primo.
La richiesta di challenge in arrivo appare in access.log, access.letsencypt.log è vuoto.
Ho trovato un file /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf che sembra restituire sempre 301 https://community.site per qualsiasi richiesta alla porta 80.
Ah, vedo che c’era dell’altro, puoi leggerlo qui fino alla fine di quell’argomento e poi vedrai che c’è stata un’altra correzione il 22 dicembre. Quindi questo spiega perché l’hai riscontrato.
Ho controllato il commit, l’ho installato. Ma penso che ci sia un errore lì.
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
dovrebbe essere return 301 https://${DISCOURSE_HOSTNAME}\\$request_uri;
Per favore, correggimi se sbaglio.
