Tengo un contenedor Docker de Discourse ejecutándose en Ubuntu (creado a partir de la plantilla de DO) con “OAuth2 personalizado” habilitado. Funciona muy bien, excepto que falla al actualizar su certificado Letsencrypt.
Rastreando el problema, veo en los registros que el script de actualización se ejecuta mediante Cron, pero el desafío es rechazado ya que Discource redirige la devolución de llamada del desafío al IDP de OAuth2.
Aquí están los registros (con información redactada):
[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.
Recompilar la aplicación soluciona el problema durante los próximos 3 meses, pero me gustaría solucionarlo correctamente. ¿Alguna sugerencia?
No estoy seguro de ver algo obvio aquí, pero honestamente simplemente pondría la configuración detrás de un proxy inverso y terminaría el ssl allí, luego usaría la validación DNS en su lugar. (esto es solo una solución temporal, no una solución porque el problema es desconocido)
Más información sobre el problema:
Puedo ver la solicitud entrante de acme-challenge a http://community.site/.well-known/…
Se redirige a https://community.site/ y luego se redirige a /oauth_basic. La segunda redirección es muy esperada, pero no la primera.
La solicitud de desafío entrante aparece en access.log, access.letsencypt.log está vacío
Encontré un archivo /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf que parece devolver siempre un 301 https://community.site para cualquier solicitud al puerto 80.
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.
Revisé el commit, lo tengo instalado. Pero creo que hay un error ahí.
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
debería ser return 301 https://${DISCOURSE_HOSTNAME}\\$request_uri;
Por favor, corríjanme si estoy equivocado.
