प्रोक्सी प्रयोग गर्दा प्रमाणपत्रका त्रुटिहरू
प्रमाणपत्रका सेटिङ बदल्नुअघि प्रमाणीकरण प्रोक्सीको आफ्नै TLS जडानमा असफल भयो कि गन्तव्य वेबसाइटमा, पहिचान गर्नुहोस्।
CA बन्डल बदल्नुअघि कुन TLS ह्यान्डसेक असफल भयो पत्ता लगाउनुहोस्। प्रोक्सी र वेबसाइटका प्रमाणपत्र फरक जडानहरूमा जाँचिन सक्छन्।
| प्रोक्सी र गन्तव्य | TLS जाँचहरू |
|---|---|
| HTTPS गन्तव्यका लागि HTTP प्रोक्सी | CONNECT पछि टनेलबाट गन्तव्यको प्रमाणपत्र प्रमाणीकरण गर्नुहोस्। |
| HTTPS गन्तव्यका लागि HTTPS प्रोक्सी | पहिले प्रोक्सीसम्मको TLS प्रमाणीकरण गर्नुहोस्; टनेल खुलेपछि गन्तव्यको छुट्टै 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 समायोजनको होइन।