तपासणी प्रॉक्सीच्या कोणत्या बाजूने प्रमाणपत्र नाकारले?

क्लायंट मंजूर तपासणी प्रॉक्सीवर विश्वास ठेवतो. तरीही प्रमाणपत्र त्रुटीमुळे विनंती अयशस्वी होते. दोन्ही तथ्ये खरी असू शकतात: त्या प्रॉक्सीचा पडताळण्यासाठी आणखी एक TLS संबंध आहे.

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

इंटरसेप्शन व्यवस्थेत मध्यस्थ क्लायंटचे TLS संपवतो आणि पुढे स्वतःचे कनेक्शन तयार करतो. क्लायंट आपल्या बाजूने सादर केलेले प्रमाणपत्र स्वीकारू शकतो, तर प्रॉक्सी वेबसाइटकडून मिळालेले प्रमाणपत्र नाकारते.

पडताळणीकर्त्याची त्रुटी वाचा

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

उदाहरणार्थ Mitmproxy स्वतंत्र अपस्ट्रीम विश्वास पर्यायांची नोंद करते, त्यात ssl_verify_upstream_trusted_ca चा समावेश आहे. योग्य प्रशासक पडताळणी टिकवून अपस्ट्रीम सेवेसाठी मंजूर विश्वास संरचीत करू शकतो. दुसऱ्या प्रॉक्सी उत्पादनास त्याचा संबंधित इंटरफेस आवश्यक आहे.

प्रत्यक्ष गंतव्य नाव आणि साखळी देखील तपासा. मध्यस्थ नसलेली खाजगी सेवा, कालबाह्य प्रमाणपत्र आणि अज्ञात खाजगी जारीकर्ता यांना वेगवेगळी दुरुस्ती लागते. एका खाजगी सेवेसाठी हेतू असलेला अपवाद शांतपणे प्रत्येक प्रमाणपत्राची जागतिक स्वीकृती बनू नये.

साधा CONNECT बोगदा वेगळा आहे

अपारदर्शक फॉरवर्ड बोगदा गंतव्य TLS अशा प्रकारे विभाजित करत नाही. सामान्यतः अनुप्रयोग स्वतः ते एंड-टू-एंड TLS सत्र वाटाघाटी करतो आणि पडताळतो. कोणत्याही मध्यस्थावर तपासणी-प्रॉक्सी सेटिंग्ज लागू करण्याऐवजी इंटरसेप्शन खरोखर मार्गाचा भाग आहे का हे प्रथम ठरवा.

दोन्ही पडताळणी निकाल वेगळे नोंदवा. “प्रॉक्सीचे प्रमाणपत्र विश्वासार्ह आहे” हे क्लायंट-बाजूच्या प्रश्नाचे उत्तर देते; प्रॉक्सीने वर जोडताना काय पाहिले याची ते साक्ष देत नाही.