J’ai un conteneur Docker Discourse fonctionnant sous Ubuntu (créé à partir du modèle DO) avec l’option « OAuth2 personnalisé » activée. Cela fonctionne très bien, sauf que la mise à jour de son certificat Letsencrypt échoue.
En recherchant le problème, je constate dans les journaux que le script de mise à jour est exécuté par Cron, mais que le défi est rejeté car Discource redirige la notification de rappel du défi vers l’IDP OAuth2.
Voici le journal (rédigé) :
\[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 reconstruction de l’application corrige le problème pour les 3 prochains mois, mais j’aimerais le résoudre correctement. Des suggestions ?
Je ne suis pas sûr de voir quelque chose d’évident ici, mais honnêtement, je placerais simplement la configuration derrière un proxy inverse et y terminerai le ssl, puis utiliserais la validation DNS à la place. (ceci n’est qu’une solution de contournement, pas une solution car le problème est inconnu)
Plus d’informations sur le problème :
Je peux voir la requête entrante acme-challenge vers http://community.site/.well-known/…
Elle est redirigée vers https://community.site/ puis redirigée vers /oauth_basic. La deuxième redirection est tout à fait attendue, mais pas la première.
La requête de défi entrante apparaît dans access.log, access.letsencypt.log est vide.
J’ai trouvé un fichier /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf qui semble toujours retourner un 301 https://community.site pour toute requête vers le port 80.
Ah, je vois qu’il y avait plus à cela, vous pouvez lire à ce sujet ici jusqu’à la fin de ce sujet et vous verrez alors qu’il y a eu un autre correctif le 22 décembre. Cela explique donc pourquoi vous l’avez rencontré.
J’ai regardé le commit, je l’ai installé. Mais je pense qu’il y a une erreur là.
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
devrait être return 301 https://${DISCOURSE_HOSTNAME}\\$request_uri;
Veuillez me corriger si je me trompe.
