Hosted-by-discourse يستخدم شهادات SSL منتهية الصلاحية بينما صفحة الحالة خضراء

الدعم
1

هذا يوقف عمل موقعنا حاليًا، ويبدو أن جميع المنشورات هنا تتعلق بالمواقع المستضافة ذاتيًا.

❯ openssl s_client -connect (removed).com:443 -servername (removed).com
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=(removed).com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

تُرجع نقاط نهاية واجهة برمجة التطبيقات (API) لنا خطأً يتعلق بشهادة منتهية الصلاحية، وقد تم التحقق من ذلك عبر Postman.

2

@الفريق يرجى المساعدة هنا

3

همم. هذا يبدو غريبًا

4

يبدو هذا حقًا وكأنه مشكلة من جانبك (أي من جانب موقعك الإلكتروني).
الشهادة المقدمة من الخادم سليمة، ومعظم المتصفحات تقبلها. المشكلة هي أن العديد من الخوادم الأقدم لا تحتوي على شهادة الجذر (الجديدة نسبيًا) في مخزن الثقة لديها، مما يتسبب في ظهور أخطاء للعديد من العمليات المؤتمتة حاليًا.

بما أنني لا أعرف موقعك بالضبط، فقد اخترت موقعًا عشوائيًا من نوع hosted-by-discourse.com وقمت بتشغيله عبر اختبار خادم SSL الخاص بـ Qualys.

image
image854×760 37.7 KB

يمكنك رؤية أن جذر المسار الثاني للشهادات منتهي الصلاحية بالفعل، لكن هذا تم معالجته من خلال وجود شهادة ISRG Root X1 في مخزن الثقة (أي مدرجة في متصفحك و/أو نظام التشغيل) الخاص بالمسار الأول للشهادات.

عادةً لا تقوم الخوادم بتحديث مخزن الثقة لديها بشكل متكرر، لذا من المرجح أن خادمك لا يحتوي على شهادة ISRG Root X1 في مخزن الثقة لديه. (وهو ما حدث أيضًا لصورة Docker الخاصة باستلام البريد).

يمكنك العثور على حزمة حديثة على سبيل المثال في https://curl.se/ca/cacert.pem. في CentOS، ينتقل هذا الملف إلى /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. أما في Ubuntu، فيمكنك استخدام أمر update-ca-certificates الذي يقوم بتحديث /etc/ssl/certs/ca-certificates.crt.

بدلاً من ذلك، يمكنك تعطيل التحقق من شهادة SSL مؤقتًا في كود الخادم الخاص بك.

5

لقد نشرت مخرجات openssl لإثبات أن الأمر لا علاقة له بموقعنا الإلكتروني، بالإضافة إلى أن Postman يتم تشغيله من جهاز Windows محلي.

تعديل: لست على دراية كافية بمستويات مختلفة من مخازن الثقة، سأبحث في الأمر أكثر، حيث يحدث هذا من كل جهاز نجربه.

6

هل لا يفشل عند استخدام متصفح حقيقي، صحيح؟

تحرير: المزيد من الأشخاص يواجهون مشاكل مع Postman، لذا أعتقد أن هذا ليس اختبارًا صالحًا… :thinking:

7

هذا رد تلقيته من مسؤول عمليات التطوير لدينا.

المشكلة تكمن في وجود نسختين من شهادة الجذر ISRG Root X1؛ أحدهما صدرت عن DST Root CA X3 منذ فترة طويلة، بينما النسخة الأحدث موقعة ذاتيًا من قِبل ISRG (الجهة التي تدير Let’s Encrypt وغيرها من الخدمات). وقد اعتمدت هذه الشهادة الموقعة ذاتيًا كجذر موثوق على معظم الأنظمة حاليًا.

كلا النسختين تمثلان نفس شهادة التوقيع، لذا يمكن التحقق من أي شيء يدعي صدوره عن ‘ISRG Root X1’ باستخدام أي من النسختين. غير أن النسخة الموقعة من قِبل DST لم تعد صالحة كسلسلة اعتماد، لأن شهادة DST التي وقعتها قد انتهت صلاحيتها.

لو كان الخادم يتصرف بشكل صحيح ويقدم النسخة الأحدث من ISRG Root X1 الموقعة ذاتيًا، لقام العميل بمقارنة الشهادة المقدمة مع مخزن الثقة الخاص به، وتأكد من تطابق الشهادة، مما كان سيؤدي إلى نجاح العملية. لكن في الواقع، عندما يرى العميل الشهادة المقدمة، يقول: “حسنًا، أحتاج إلى التحقق منها مقابل DST Root CA X3 الموجودة في ملفاتي… أوه، لقد انتهت صلاحيتها”، فيفشل التحقق.

8

تقديم شهادة في سلسلة الشهادات يُتوقع أن تكون موجودة في مخزن جذور CA الموثوقة هو أمر بعيد كل البعد عن “القيام بالصواب”.

دعنا ننظر إلى سلسلة الشهادات من letsencrypt.org نفسها: SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

ها هو، انظر. إنهم يفعلون نفس الشيء، سلسلة الشهادات متطابقة (باستثناء شهادة الخادم بالطبع).

image
image812×744 33.1 KB

إذن إما أن موظف التشغيل والتطوير (devops) مخطئ، أو أن CDCK وLetsEncrypt وQualys جميعها مخطئة.
أخبره بتحديث مخزن جذور CA. سيحل هذه المشكلة. صدقني.

9

مرحبًا @bpaterson2000، نأسف لسماع أنك تواجه مشاكل في الاتصال بخدّمنا المستضافة. وكما ذكر @RGJ، فإن المشكلة ليست من جانب Discourse، بل يجب حلها من جانب عميلك. (خوادمنا لا ‘تزود’ بشهادة الجذر، بل تُدار بواسطة عميلك)

يمكنك العثور على مزيد من التفاصيل حول هذا التغيير من Let’s Encrypt هنا:

10

شكرًا على المعلومات، لقد كانت هذه مشكلة غير متوقعة بالنسبة لنا، حيث كانت الأخطاء تعود في الظاهر من الخادم المستضاف.

نحن نستخدم Heroku الذي يجمع العناصر التي تتحدث عنها عبر node/h packages، ويبدو أن تحديث node كان المفتاح لإعادة الاتصال بنجاح بـ Discourse REST API.

شكرًا على مساعدتك.