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 बदलाशी नाही.

संबंधित लेख