أي طرف من وسيط الفحص رفض الشهادة؟

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

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

في ترتيب الاعتراض، ينهي الوسيط جلسة TLS الخاصة بالعميل وينشئ اتصاله الخاص صعودًا. يمكن للعميل أن يقبل الشهادة المعروضة من جهته بينما يرفض الوسيط الشهادة التي يتلقاها من الموقع.

اقرأ خطأ المُتحقِّق

حدِّد العملية التي أبلغت عن فشل السلسلة أو اسم المضيف. يمكن لصفحة خطأ يولّدها الوسيط أن تصل إلى العميل بنجاح عبر اتصال صالح. وتغيير ملف CA الخاص بالعميل مرة أخرى لا يُحدِّث إعدادات الثقة الصاعدة للوسيط.

يوثِّق Mitmproxy، على سبيل المثال، خيارات ثقة صاعدة منفصلة، منها ssl_verify_upstream_trusted_ca. ويمكن للمسؤول المختص تهيئة ثقة معتمدة للخدمة الصاعدة مع الحفاظ على التحقق. أما منتج وسيط آخر فيحتاج إلى واجهته المقابلة.

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

نفق CONNECT العادي مختلف

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

سجِّل نتيجتي التحقق بشكل منفصل. فالعبارة “شهادة الوسيط موثوقة” تجيب عن سؤال جهة العميل؛ لكنها لا تشهد بما رآه الوسيط حين اتصل صاعدًا.