I have a Discourse Docker container running on Ubuntu (created from DO template) with “Custom OAuth2” enabled. Works very well, expect it fails to update its Letsencrypt certificate. Tracking down the problem I can see from the logs that the update script is executed by Cron, but the challenge gets rejected as Discource redirects the challenge callback to OAuth2 IDP. Here is the (redacted) log: [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. Rebuild app fixes the issue for next 3 months but I would like to fix it properly. Any suggestions? Thanks in advance.

I’m not sure I see something obvious here, but honestly I would just put the setup behind a reverse proxy and terminate ssl there, then use DNS validation instead. (this is just a workaround, not a solution because problem is unknown)

More info on the issue: I can see the incoming acme-challenge request to http://community.site/.well-known/… It gets redirected to https://community.site/ and then redirected to /oauth_basic. The second redirect is very well expected, but not the first one. The incoming challenge request appears in access.log, access.letsencypt.log is empty I found a /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf that seems always to return 301 https://community.site for any request to port 80.

[imagen] Ostap1974: I found a /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf that seems always to return 301 https://community.site for any request to port 80. That issue has been fixed last August, letsencrypt updates: renew location for .well-known, add support for … · discourse/discourse_docker@ae4887a · GitHub

Interesting, I rebuilt the app on Nov 26th, so I would expect the fix included by then… Anyway, thank you all for help. Let’s close the topic and hope the issue will not return after next rebuild.

Ah, I see there was more to it, you can read about that here to the end of that topic and then you will see there was another fix on December 22. So that explains why you encountered it.

Looked the commit, I have it insalled. But I think there is a mistake there. return 301 https://${DISCOURSE_HOSTNAME}$request_uri; should be return 301 https://${DISCOURSE_HOSTNAME}\$request_uri; Please correct me if I am wrong.

That is exactly what the other fix I mentioned, fixes [image]

Conflicto entre OAuth2 y Letsencrypt

Soporte del producto

RGJ (Richard - Communiteq) 28 Enero, 2026 15:52 6

Ah, veo que había más, puedes leer sobre eso aquí hasta el final de ese tema y luego verás que hubo otra corrección el 22 de diciembre. Así que eso explica por qué lo encontraste.

Tema		Respuestas	Vistas
Let's Encrypt cert renewals (suddenly) failing Self-hosting	26	3559	28 Diciembre 2021
Discourse failure to renew certificate Bug letsencrypt	24	1398	23 Diciembre 2025
LetsEncrypt certificate not renewing Self-hosting letsencrypt	6	600	9 Diciembre 2024
Hit Let's encrypt renewal limit Self-hosting	6	2344	1 Julio 2020
Letsencrypt not renewing Self-hosting	5	1666	14 Julio 2017

Conflicto entre OAuth2 y Letsencrypt

Temas relacionados