सामान्य CONNECT मार्फत HTTPS मा, अनुप्रयोगले आफ्नै गन्तव्य TLS ह्यान्डसेकका बेला वेबसाइटको ग्राहक प्रमाणपत्र पठाउँछ। प्रोक्सीले बाइटहरू मात्र रिले गर्छ; यो स्वतः वेबसाइटको TLS ग्राहक बन्दैन।

प्रमाणमालिक/जडान
प्रोक्सी प्रयोगकर्तानाम/पासवर्डप्रोक्सीमा ग्राहकको पहुँच।
वेबसाइटको ग्राहक प्रमाणपत्र र निजी कुञ्जीगन्तव्यसँग अनुप्रयोगको TLS सत्र।
प्रोक्सी सर्भरको माथिल्लो ग्राहक प्रमाणपत्रप्रोक्सी आफैँले सुरु गर्ने TLS सत्र।

यी भूमिकाहरू सँगै रहन सक्छन्। गन्तव्य mTLS काम गर्न वेबसाइटको निजी कुञ्जी साधारण टनेलिङ प्रोक्सीमा अपलोड गर्न आवश्यक छैन। CONNECT हस्तान्तरणपछि, अनुप्रयोगको सामान्य गन्तव्य ग्राहक-प्रमाणपत्र कन्फिगरेसन प्रयोग गर्नुहोस् र वेबसाइट सर्भर प्रमाणपत्र प्रमाणित गर्न जारी राख्नुहोस्।

Apache को SSLProxyMachineCertificateFile ले Apache आफ्नै माथिल्लो TLS सत्र सिर्जना गर्दा प्रमाणहरू उपलब्ध गराउँछ। त्यो फाइलबारेको सल्लाहले अस्पष्ट फर्वार्ड टनेल प्रयोग गर्ने हरेक ग्राहकले यसलाई कन्फिगर गर्नैपर्छ भनी प्रमाणित गर्दैन।

TLS अवरोधले मध्यस्थतामा सत्र अन्त्य गर्छ र यो स्वामित्व बदल्छ। प्रमाणपत्रको प्रतिलिपिले छेउदेखि छेउसम्मको प्रमाणीकरण जोगाउँछ भनी मान्नुको सट्टा आवश्यक ग्राहक पहिचान त्यस व्यवस्थाबाट जान सक्छ कि सक्दैन निर्धारण गर्नुहोस्।

असफलता हुँदा, अनुरोध प्रोक्सी लगइनमा, गन्तव्य TLSमा वा पछिको अनुप्रयोग आदानप्रदानमा रोकियो कि भनी अभिलेख गर्नुहोस्। प्रमाणलाई वास्तवमै यसको माग गर्ने जडानमा राख्नुहोस्।

सम्बन्धित लेखहरू