Конфликт между OAuth2 и Letsencrypt

Поддержка
,
1

У меня запущен контейнер Discourse Docker на Ubuntu (создан по шаблону DO) с включённой функцией «Custom OAuth2». Работает отлично, за исключением того, что обновление сертификата Letsencrypt не удаётся.

При поиске проблемы я обнаружил в логах, что скрипт обновления запускается через Cron, но проверка отклоняется, так как Discourse перенаправляет обратный вызов проверки на OAuth2 IDP.

Вот (частично скрытый) лог:
[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.

Пересборка приложения решает проблему на следующие 3 месяца, но я хотел бы исправить её окончательно. Есть какие-либо предложения?

Заранее спасибо.

2

Не уверен, что здесь что-то очевидное, но честно говоря, я бы просто настроил обратный прокси-сервер и завершил SSL-соединение там, а затем использовал бы валидацию через DNS. (это просто обходной путь, а не решение, так как причина проблемы неизвестна)

3

Дополнительная информация о проблеме:
Я вижу входящий запрос acme-challenge на http://community.site/.well-known/…
Он перенаправляется на https://community.site/, а затем на /oauth_basic. Второе перенаправление вполне ожидаемо, но первое — нет.

Входящий запрос проверки появляется в access.log, а access.letsencypt.log пуст.

Я обнаружил файл /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf, который, похоже, всегда возвращает 301 с адресом https://community.site для любого запроса на порт 80.

4

Эта проблема была исправлена в прошлом августе: letsencrypt updates: renew location for .well-known, add support for … · discourse/discourse_docker@ae4887a · GitHub

5

Интересно, я собрал приложение 26 ноября, так что я ожидал, что исправление уже будет включено к тому времени…

В любом случае, спасибо всем за помощь. Давайте закроем тему и надеемся, что проблема не вернётся после следующей сборки.

6

Ага, я понял, что дело было не только в этом. Вы можете прочитать об этом здесь, до конца темы, а затем увидите, что 22 декабря было применено ещё одно исправление. Так что теперь понятно, почему вы столкнулись с этой проблемой.

7

Я посмотрел коммит, у меня он установлен. Но, кажется, там ошибка.

return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
должно быть
return 301 https://${DISCOURSE_HOSTNAME}\$request_uri;

Поправьте меня, если я не прав.

8

Это именно то, что исправляет другое исправление, о котором я упоминал.

image
image1103×272 9.27 KB

9

Ещё раз спасибо, очень помогли!