أخطاء TLS على شبكة الشركة فقط: أصلح مخزن الثقة الصحيح
الأداة نفسها والحاسوب نفسه، والشبكة الخاصة وحدها تعطّل TLS. اقرأ الرسالة، واعثر على حزمة شهادات CA التي يقرأها الملف التنفيذي، وأضف جذرًا واحدًا بدل تعطيل التحقق.
نسخة Go وتركيب Composer وعميل Python كلها تعمل في المنزل وكلها تفشل داخل شبكة الشركة الخاصة. هذا النمط يخبرك عن المسار لا عن التطبيق. شيء ما على النفق غيّر سلسلة الشهادات التي تراها عمليتك، أو أعاد تصفير المصافحة قبل أن تصل أي سلسلة إطلاقًا. العطلان يبدوان متشابهين في الطرفية ويحتاجان إلى استجابتين مختلفتين تمامًا.
ثلاث رسائل، ثلاث آليات
خطأ شهادة x509 موقّعة من جهة غير معروفة يعني أنه بُنيت سلسلة وجذرها مفقود من مخزن الثقة الذي تستخدمه تلك العملية. وخطأ شهادة موقّعة ذاتيًا داخل سلسلة الشهادات يعني عادةً أن وكيل فحص ردّ بشهادته الخاصة، وهي سلسلة لا يتعرف عليها وقت تشغيلك. وخطأ SSL EOF أثناء المصافحة يعني أن الاتصال أُغلق قبل إرسال أي شهادة صالحة للاستخدام، وذلك صندوق وسيط يرفض ClientHello وليس مشكلة ثقة على الإطلاق.
إضافة علم عدم التحقق تجعل الرسائل الثلاث تختفي مع إبقاء الاعتراض في مكانه، وهي تزيل الفحص الذي كان سيكشف مهاجمًا حقيقيًا.
اعثر على الحزمة التي تقرأها العملية فعليًا
الجذر المؤسسي المثبّت في مخزن Windows يصلح المتصفحات وتطبيقات .NET التي تراجع مخزن النظام. وهو لا يفعل شيئًا لبناء يعمل داخل حاوية تحمل حزمة CA خاصة بها، ولا لعملية Python تستخدم certifi أو لعملية Node تستخدم قائمتها المضمّنة. أما Go فيقرأ مجمّع النظام الخاص بالبيئة التي يعمل فيها الملف التنفيذي، وهي الحاوية لا الحاسوب المحمول. لذلك ينتج جهاز واحد متصفحًا يعمل وأداة بناء تفشل في الوقت نفسه.
اسأل الأداة بدل أن تفترض. الأمر python3 -c "import ssl; print(ssl.get_default_verify_paths())" يطبع الملفات التي ستراجعها Python، والأمر node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" يُظهر ما إذا كان تجاوز ما مضبوطًا بالفعل. أما الحاوية، فشغّل الفحص نفسه داخل الصورة، لأنها البيئة التي يستخدمها البناء فعليًا.
ثبّت جذرًا واحدًا حيث يجري البناء
احصل على جذر الفحص من قسم تقنية المعلومات كملف PEM وتحقق من بصمته عبر قناة منفصلة قبل الوثوق به. على الصور المبنية على Debian، انسخه إلى /usr/local/share/ca-certificates/ وشغّل update-ca-certificates؛ أما صور عائلة RHEL فتستخدم update-ca-trust بعد إسقاط الملف في /etc/pki/ca-trust/source/anchors/. في بناء الحاوية، أضف تلك الخطوات قبل الأمر الفاشل كي تُخزَّن الطبقة فوق تثبيت التبعيات.
لحاوية تطوير محلية، اربط ملف PEM وشغّل أمر التحديث نفسه عند البدء بدل خبزه في صورة شخصية لا يستطيع أحد غيرك إعادة إنتاجها. الأدوات التي تحمل حزمتها الخاصة تحتاج تجاوزًا موثقًا خاصًا بها: pip لديه إعداد شهادة، وnpm لديه إعداد cafile، ومعظم الأدوات الأخرى تقبل متغيرات البيئة القياسية.
هذا ليس مثل قبول أي شهادة. أنت تضيف جذرًا واحدًا محددًا، حصلت عليه من الجهة التي تجري الفحص، إلى بيئة واحدة، ويبقى التحقق مفعّلًا لكل سلسلة أخرى. سجّل أي ملف أُضيف ومتى تنتهي صلاحيته، لأن جذر الفحص يُجدَّد مثل أي CA آخر.
عندما تموت المصافحة قبل وصول شهادة
إذا لم يُقدَّم شيء، فلن يساعد أي تغيير في مخزن الثقة. قارن الطلب نفسه مع النفق مفتوحًا ومغلقًا، ثم افحص السلسلة مباشرة باستخدام openssl s_client -connect host:443 -servername host -showcerts. الاتصال الذي يكتمل خارج الشبكة الخاصة ويُعاد تصفيره داخلها قرار سياسة يتخذه الصندوق الوسيط، والعلاج استثناء لذلك المضيف لا شهادة أخرى. اطلب السماح لمستودع الحزم أو نقطة نهاية API بالمرور دون تعديل.
تقسيم النفق كي تتجاوز الأداة الشبكة الخاصة يتجنب الفحص لحركة المرور تلك، وقد يخالف السياسة ولا يجعل الأداة موثوقة.
دوّن النتيجة لكل أداة
ملاحظة قصيرة تسرد الملف التنفيذي، وملف الثقة الذي يقرأه، والمتغير البيئي المستخدم، والاستثناء المعتمد، توفّر على الشخص التالي التشخيص كله. احتفظ بالملاحظة لكل أداة لا لكل حاسوب، لأن الحاسوب نادرًا ما يكون الشيء الذي تغيّر.
وافصل جملتين في التذكرة: ثبّتنا جذرًا مؤسسيًا محددًا، وأوقفنا التحقق. واحدة فقط من هاتين الخطوتين إجراء دعم.