जाँच प्रॉक्सी के किस पक्ष ने प्रमाणपत्र को अस्वीकार किया?

क्लाइंट स्वीकृत जाँच प्रॉक्सी पर भरोसा करता है। फिर भी अनुरोध प्रमाणपत्र त्रुटि के कारण विफल होता है। दोनों तथ्य सत्य हो सकते हैं: उस प्रॉक्सी का सत्यापित करने के लिए एक और TLS संबंध है।

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

इंटरसेप्शन व्यवस्था में मध्यस्थ क्लाइंट का TLS समाप्त करता है और आगे अपना संबंध बनाता है। क्लाइंट अपनी ओर प्रस्तुत प्रमाणपत्र स्वीकार कर सकता है, जबकि प्रॉक्सी वेबसाइट से मिला प्रमाणपत्र अस्वीकार करता है।

सत्यापनकर्ता की त्रुटि पढ़ें

निर्धारित करें कि किस प्रक्रिया ने विफल श्रृंखला या होस्टनाम की सूचना दी। प्रॉक्सी द्वारा उत्पन्न त्रुटि पृष्ठ किसी वैध कनेक्शन पर क्लाइंट तक सफलतापूर्वक पहुँच सकता है। क्लाइंट की CA फ़ाइल फिर से बदलने से प्रॉक्सी का अपस्ट्रीम ट्रस्ट कॉन्फ़िगरेशन अपडेट नहीं होता।

उदाहरण के लिए Mitmproxy अलग अपस्ट्रीम ट्रस्ट विकल्पों का दस्तावेज़ीकरण करता है, जिनमें ssl_verify_upstream_trusted_ca शामिल है। उपयुक्त प्रशासक सत्यापन बनाए रखते हुए अपस्ट्रीम सेवा के लिए स्वीकृत ट्रस्ट कॉन्फ़िगर कर सकता है। किसी अन्य प्रॉक्सी उत्पाद को अपना संगत इंटरफ़ेस चाहिए।

वास्तविक गंतव्य नाम और श्रृंखला भी जाँचें। मध्यवर्ती के बिना निजी सेवा, समाप्त प्रमाणपत्र और अपरिचित निजी जारीकर्ता के लिए अलग-अलग मरम्मत चाहिए। एक निजी सेवा के लिए इच्छित अपवाद चुपचाप हर प्रमाणपत्र की वैश्विक स्वीकृति नहीं बनना चाहिए।

साधारण CONNECT सुरंग अलग है

अपारदर्शी फ़ॉरवर्ड सुरंग गंतव्य TLS को इस तरह विभाजित नहीं करती। एप्लिकेशन आमतौर पर उस एंड-टू-एंड TLS सत्र पर स्वयं बातचीत करता है और उसे सत्यापित करता है। पहले निर्धारित करें कि इंटरसेप्शन वास्तव में मार्ग का हिस्सा है या नहीं, बजाय किसी भी मध्यस्थ पर जाँच-प्रॉक्सी सेटिंग्स लागू करने के।

दोनों सत्यापन परिणाम अलग-अलग दर्ज करें। “प्रॉक्सी का प्रमाणपत्र विश्वसनीय है” क्लाइंट-पक्ष के प्रश्न का उत्तर देता है; यह प्रमाणित नहीं करता कि प्रॉक्सी ने ऊपर जुड़ते समय क्या देखा।