لدي حاوية Docker خاصة بـ Discourse تعمل على Ubuntu (تم إنشاؤها من قالب DigitalOcean) مع تمكين “Custom OAuth2”. إنها تعمل بشكل جيد للغاية، باستثناء أنها تفشل في تحديث شهادة Letsencrypt الخاصة بها.
بتتبع المشكلة، أرى من السجلات أن برنامج التحديث النصي يتم تنفيذه بواسطة Cron، ولكن يتم رفض التحقق لأن Discource يعيد توجيه استدعاء التحقق إلى موفر هوية OAuth2 (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.
إعادة بناء التطبيق (Rebuild app) يحل المشكلة للأشهر الثلاثة القادمة، ولكني أرغب في إصلاحها بشكل صحيح. أي اقتراحات؟
لست متأكدًا من أنني أرى شيئًا واضحًا هنا، ولكن بصراحة، سأضع الإعداد خلف وكيل عكسي (reverse proxy) وأنهي شهادة SSL هناك، ثم أستخدم التحقق عبر نظام أسماء النطاقات (DNS validation) بدلاً من ذلك. (هذا مجرد حل بديل، وليس حلاً لأن المشكلة غير معروفة)
مزيد من المعلومات حول المشكلة:
أرى طلب التحقق 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.
آه، أرى أن الأمر كان أعمق من ذلك، يمكنك قراءة المزيد حول ذلك هنا حتى نهاية ذلك الموضوع وستلاحظ بعد ذلك أنه كان هناك إصلاح آخر في 22 ديسمبر. وهذا يفسر سبب مواجهتك له.
