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.

[image] 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]

OAuth2 and Letsencrypt clash

Product Support

RGJ (Richard - Communiteq) January 28, 2026, 4:01pm 8

That is exactly what the other fix I mentioned, fixes

Topic		Replies	Views
Let's Encrypt cert renewals (suddenly) failing Self-hosting	26	3549	December 28, 2021
Discourse failure to renew certificate Bug letsencrypt	24	1362	December 23, 2025
LetsEncrypt certificate not renewing Self-hosting letsencrypt	6	589	December 9, 2024
Hit Let's encrypt renewal limit Self-hosting	6	2338	July 1, 2020
Letsencrypt not renewing Self-hosting	5	1655	July 14, 2017

OAuth2 and Letsencrypt clash

Related topics