HTTPS प्रोक्सीले पनि आफ्नो प्रमाणपत्र शृंखला पठाउनुपर्छ

यदि ग्राहकहरूले वेबसाइटमा पुग्नुअघि HTTPS प्रोक्सी अस्वीकार गर्छन् भने, प्रोक्सी सुन्नेले पठाउने शृंखला जाँच्नुहोस्। एउटा मात्र वैध पातलो प्रमाणपत्रले ग्राहकलाई आवश्यक मध्यस्थ प्रमाणपत्रहरू दिन नसक्न सक्छ।

1. जाँचिँदै गरेको अन्त्य बिन्दु पहिचान गर्नुहोस्। कन्फिगर गरिएको प्रोक्सी URL मा भएको होस्टनाम र त्यो जडानको त्रुटि पढ्नुहोस्। सुन्नेको प्रमाणपत्रले त्यो नाम समेट्नुपर्छ। कुनै वेबसाइटको प्रमाणपत्र वा अर्को IP उपनामको प्रमाणपत्रले यसलाई प्रतिस्थापन गर्न सक्दैन।
2. सुन्नेको शृंखला कन्फिगरेसन जाँच्नुहोस्। Squid ले समर्थन गर्ने OpenSSL कन्फिगरेसनले प्रमाणपत्र फाइलमा मध्यस्थ प्रमाणपत्रहरू समावेश गर्न सक्छ। स्थापित Squid संस्करण र TLS backend का लागि सुन्ने सन्दर्भमा व्यवस्था पुष्टि गर्नुहोस्; प्याकेजको व्यवहार एकनासको हुँदैन। Squid 6.13 को TLS सुन्ने उदाहरण ले सुन्नेको विश्वास गन्तव्यको TLS बाट अलग राख्छ।
3. ग्राहकको विश्वास अलग जाँच्नुहोस्। मध्यस्थ प्रमाणपत्रहरू पठाउनुले शृंखला बनाउन मद्दत गर्छ, तर ग्राहकलाई अझै इच्छित मूल विश्वास एङ्कर चाहिन्छ। सम्पूर्ण सर्भर शृंखला भेदभाव नगरी मूल भण्डारमा आयात गर्नु सर्भरले पठाउने कुरा सुधार्नुभन्दा फरक परिवर्तन हो।

प्रमाणीकरण खुला राख्नुहोस्। यसले ग्राहकले प्रयोग गर्न खोजेको HTTPS प्रोक्सी पहिचान गर्छ। त्यो जडान प्रमाणित भएपछि, पछिको वेबसाइट प्रमाणपत्र त्रुटि प्रोक्सीमार्फत गन्तव्यको TLS सत्र को हो, जसको आफ्नै होस्टनाम र विश्वास अन्वेषण हुन्छ।