Tenho um contêiner Docker do Discourse rodando no Ubuntu (criado a partir do template DO) com “OAuth2 Personalizado” ativado. Funciona muito bem, exceto que falha ao atualizar seu certificado Letsencrypt.
Rastreando o problema, vejo nos logs que o script de atualização é executado pelo Cron, mas o desafio é rejeitado porque o Discource redireciona o callback do desafio para o IDP do OAuth2.
Aqui está o log (redigido):
\[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.
Reconstruir o aplicativo corrige o problema pelos próximos 3 meses, mas eu gostaria de consertá-lo adequadamente. Alguma sugestão?
Não tenho certeza se vejo algo óbvio aqui, mas honestamente eu apenas colocaria a configuração atrás de um proxy reverso e encerraria o ssl lá, depois usaria a validação DNS. (isso é apenas uma solução alternativa, não uma solução porque o problema é desconhecido)
Mais informações sobre o problema:
Consigo ver a requisição acme-challenge de entrada para http://community.site/.well-known/…
Ela é redirecionada para https://community.site/ e depois redirecionada para /oauth_basic. O segundo redirecionamento é totalmente esperado, mas não o primeiro.
A requisição de desafio de entrada aparece no access.log, o access.letsencypt.log está vazio.
Encontrei um /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf que parece sempre retornar 301 https://community.site para qualquer requisição para a porta 80.
Ah, vejo que havia mais a isso, você pode ler sobre isso aqui até o final desse tópico e então verá que houve outra correção em 22 de dezembro. Então isso explica por que você a encontrou.
Olhei o commit, eu o tenho instalado. Mas acho que há um erro aí.
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
deve ser return 301 https://${DISCOURSE_HOSTNAME}\\$request_uri;
Por favor, me corrija se eu estiver errado.
