إذا رفض العملاء وكيل HTTPS قبل الوصول إلى موقع ما، فافحص السلسلة التي يرسلها مستمع الوكيل. قد لا تكفي شهادة طرفية صالحة وحدها لتوفير الشهادات الوسيطة التي يحتاجها العميل.

  1. حدِّد نقطة النهاية التي يجري فحصها. اقرأ اسم المضيف في عنوان URL المهيأ للوكيل والخطأ الخاص بذلك الاتصال. يجب أن تغطي شهادة المستمع ذلك الاسم. ولا يمكن لشهادة موقع أو شهادة باسم مستعار آخر لعنوان IP أن تحل محلها.
  2. افحص تهيئة السلسلة لدى المستمع. يمكن لتهيئة OpenSSL المدعومة في Squid أن تضمّن الشهادات الوسيطة في ملف الشهادة. تحقق من الترتيب في مرجع المستمع الخاص بإصدار Squid المثبت وخلفية TLS؛ فسلوك الحزم ليس موحدًا. مثال مستمع TLS في Squid 6.13 يُبقي ثقة المستمع منفصلة عن TLS الخاص بالوجهة.
  3. افحص ثقة العميل بشكل منفصل. إرسال الشهادات الوسيطة يساعد في بناء السلسلة، لكن العميل لا يزال بحاجة إلى مرساة الثقة الجذرية المقصودة. واستيراد سلسلة الخادم كاملة إلى مخزن الجذور دون تمييز تغيير مختلف عن تصحيح ما يرسله الخادم.

أبقِ التحقق مفعّلًا. فهو يحدد وكيل HTTPS الذي كان العميل ينوي استخدامه. وبعد التحقق من ذلك الاتصال، يعود خطأ شهادة الموقع اللاحق إلى جلسة TLS الخاصة بالوجهة عبر الوكيل، وله تحقيق خاص باسم المضيف والثقة.

مقالات ذات صلة