प्रॉक्सी इस्तेमाल करते समय सर्टिफ़िकेट की त्रुटियाँ

CA बंडल बदलने से पहले पता लगाएँ कि कौन-सा TLS हैंडशेक विफल हुआ। प्रॉक्सी और वेबसाइट के सर्टिफ़िकेट अलग-अलग कनेक्शन पर जाँचे जा सकते हैं।

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

curl दोनों कनेक्शन के लिए अलग CA विकल्प देता है:

curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/

--proxy-cacert प्रॉक्सी के लिए भरोसे का आधार देता है; --cacert गंतव्य के लिए। उदाहरण के एंडपॉइंट और फ़ाइलों को अपनी इच्छित ट्रस्ट व्यवस्था के मानों से बदलें। सिस्टम का भरोसा पहले ही पर्याप्त हो तो कस्टम बंडल की ज़रूरत नहीं।

होस्टनाम की जगह कोई मनमाना IP रखने से सर्टिफ़िकेट का मिलान बदलता है। सत्यापन छोड़ना विफलता को छिपा सकता है, मगर दूसरे सिरे की पहचान स्थापित नहीं करता। अनजान प्रॉक्सी का अपना रूट CA इंस्टॉल करने को कहना उस पर भरोसा करने की पर्याप्त वजह नहीं है।

पोर्ट पर कनेक्शन मना होना या CONNECT अस्वीकृत होना पहले चरण की बात है; सर्टिफ़िकेट बदलने से वह ठीक नहीं होगा। दूसरी ओर, गंतव्य का TLS सत्यापित हो जाने के बाद वेबसाइट की HTTP त्रुटि मिले हुए रिस्पॉन्स का मामला है, एक और CA बदलाव का नहीं।