प्रॉक्सी के माध्यम से क्लाइंट प्रमाणपत्र कौन भेजता है?
गंतव्य के mTLS क्रेडेंशियल को प्रॉक्सी क्रेडेंशियल से और उन प्रमाणपत्रों से अलग रखें जिनका उपयोग Apache अपना स्वयं का अपस्ट्रीम TLS सत्र बनाते समय करता है।
सामान्य CONNECT के माध्यम से HTTPS में, एप्लिकेशन अपने गंतव्य TLS हैंडशेक के दौरान वेबसाइट का क्लाइंट प्रमाणपत्र भेजता है। प्रॉक्सी केवल बाइट्स रिले करता है; वह स्वतः वेबसाइट का TLS क्लाइंट नहीं बन जाता।
| क्रेडेंशियल | स्वामी/कनेक्शन |
|---|---|
| प्रॉक्सी उपयोगकर्ता नाम/पासवर्ड | प्रॉक्सी तक क्लाइंट की पहुँच। |
| वेबसाइट का क्लाइंट प्रमाणपत्र और निजी कुंजी | गंतव्य के साथ एप्लिकेशन का TLS सत्र। |
| प्रॉक्सी सर्वर का अपस्ट्रीम क्लाइंट प्रमाणपत्र | वह TLS सत्र जो प्रॉक्सी स्वयं आरंभ करता है। |
ये भूमिकाएँ साथ रह सकती हैं। गंतव्य mTLS के काम करने के लिए वेबसाइट की निजी कुंजी को साधारण टनलिंग प्रॉक्सी पर अपलोड करना आवश्यक नहीं है। CONNECT हैंडऑफ़ के बाद, एप्लिकेशन का सामान्य गंतव्य क्लाइंट-प्रमाणपत्र कॉन्फ़िगरेशन उपयोग करें और वेबसाइट सर्वर प्रमाणपत्र का सत्यापन जारी रखें।
Apache का SSLProxyMachineCertificateFile तब क्रेडेंशियल देता है जब Apache अपना स्वयं का अपस्ट्रीम TLS सत्र बनाता है। उस फ़ाइल के बारे में सलाह यह सिद्ध नहीं करती कि अस्पष्ट फ़ॉरवर्ड टनल उपयोग करने वाले हर क्लाइंट को उसे कॉन्फ़िगर करना ही चाहिए।
TLS इंटरसेप्शन किसी मध्यस्थ पर सत्र समाप्त करता है और यह स्वामित्व बदल देता है। यह मानने के बजाय कि प्रमाणपत्र की प्रतिलिपि बनाने से छोर-से-छोर प्रमाणीकरण बना रहता है, यह निर्धारित करें कि आवश्यक क्लाइंट पहचान उस व्यवस्था से गुजर सकती है या नहीं।
विफलता पर, दर्ज करें कि अनुरोध प्रॉक्सी लॉगिन पर, गंतव्य TLS पर या बाद के एप्लिकेशन आदान-प्रदान पर रुका। क्रेडेंशियल को उस कनेक्शन पर रखें जो वास्तव में उसका अनुरोध करता है।