जाँच प्रोक्सीको कुन पक्षले प्रमाणपत्र अस्वीकार गर्‍यो?

ग्राहकले स्वीकृत जाँच प्रोक्सीमा विश्वास गर्छ। तैपनि प्रमाणपत्र त्रुटिका कारण अनुरोध असफल हुन्छ। दुवै तथ्य सत्य हुन सक्छन्: त्यो प्रोक्सीसँग प्रमाणीकरण गर्न अर्को TLS सम्बन्ध छ।

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

इन्टरसेप्सन व्यवस्थामा मध्यस्थले ग्राहकको TLS अन्त्य गरी अगाडि आफ्नै जडान बनाउँछ। ग्राहकले आफ्नो पक्षमा प्रस्तुत प्रमाणपत्र स्वीकार गर्न सक्छ, जबकि प्रोक्सीले वेबसाइटबाट प्राप्त प्रमाणपत्र अस्वीकार गर्छ।

प्रमाणीकरणकर्ताको त्रुटि पढ्नुहोस्

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

उदाहरणका लागि Mitmproxy ले ssl_verify_upstream_trusted_ca सहित छुट्टै अपस्ट्रिम विश्वास विकल्पहरू अभिलेख गर्छ। उपयुक्त प्रशासकले प्रमाणीकरण कायम राख्दै अपस्ट्रिम सेवाका लागि स्वीकृत विश्वास कन्फिगर गर्न सक्छ। अर्को प्रोक्सी उत्पादनलाई त्यसको सम्बन्धित इन्टरफेस चाहिन्छ।

वास्तविक गन्तव्य नाम र शृंखला पनि जाँच्नुहोस्। मध्यस्थ बिनाको निजी सेवा, म्याद सकिएको प्रमाणपत्र र अज्ञात निजी जारीकर्तालाई फरक मर्मत चाहिन्छ। एउटा निजी सेवाका लागि इच्छित अपवाद चुपचाप हरेक प्रमाणपत्रको विश्वव्यापी स्वीकृति बन्नु हुँदैन।

साधारण CONNECT सुरुङ फरक हुन्छ

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

दुवै प्रमाणीकरण नतिजा छुट्टाछुट्टै अभिलेख गर्नुहोस्। “प्रोक्सीको प्रमाणपत्र विश्वसनीय छ” ले ग्राहक-पक्षको प्रश्नको उत्तर दिन्छ; प्रोक्सीले माथि जोडिँदा के देख्यो भनी त्यसले प्रमाणित गर्दैन।