सामान्य CONNECT द्वारे HTTPS मध्ये, ॲप्लिकेशन त्याच्या गंतव्य TLS हँडशेक दरम्यान वेबसाइटचे क्लायंट प्रमाणपत्र पाठवते. प्रॉक्सी फक्त बाइट्स रिले करते; ते आपोआप वेबसाइटचे TLS क्लायंट होत नाही.

ओळखपत्रमालक/कनेक्शन
प्रॉक्सी वापरकर्तानाव/पासवर्डप्रॉक्सीमध्ये क्लायंटचा प्रवेश.
वेबसाइटचे क्लायंट प्रमाणपत्र आणि खाजगी कीगंतव्यासह ॲप्लिकेशनचे TLS सत्र.
प्रॉक्सी सर्व्हरचे अपस्ट्रीम क्लायंट प्रमाणपत्रप्रॉक्सी स्वतः सुरू करते ते TLS सत्र.

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

Apache चे SSLProxyMachineCertificateFile जेव्हा Apache स्वतःचे अपस्ट्रीम TLS सत्र तयार करते तेव्हा ओळखपत्रे पुरवते. त्या फाइलबद्दलचा सल्ला हे सिद्ध करत नाही की अपारदर्शक फॉरवर्ड टनेल वापरणाऱ्या प्रत्येक क्लायंटने ती कॉन्फिगर केलीच पाहिजे.

TLS अडवणूक मध्यस्थाकडे सत्र संपवते आणि ही मालकी बदलते. प्रमाणपत्राची प्रत केल्याने टोकापासून टोकापर्यंत प्रमाणीकरण टिकते असे गृहीत धरण्याऐवजी, आवश्यक क्लायंट ओळख त्या रचनेतून जाऊ शकते का हे निश्चित करा.

अपयश आल्यास, विनंती प्रॉक्सी लॉगिनवर, गंतव्य TLS वर किंवा नंतरच्या ॲप्लिकेशन देवाणघेवाणीवर थांबली का ते नोंदवा. ओळखपत्र त्या कनेक्शनवर ठेवा जे प्रत्यक्षात त्याची मागणी करते.

संबंधित लेख