CRL और OCSP प्रमाणपत्र जाँचों में प्रॉक्सी विफलताओं का पता लगाना

किसी वेबसाइट का अनुरोध अपने प्रॉक्सी तक पहुँच सकता है और फिर भी विफल हो सकता है क्योंकि प्रमाणपत्र सत्यापन के लिए एक और नेटवर्क अनुरोध चाहिए। CRL या OCSP पुनर्प्राप्ति एप्लिकेशन के HTTP क्लाइंट से भिन्न खाते और प्रॉक्सी नीति वाले प्लेटफ़ॉर्म घटक के माध्यम से चल सकती है।

सटीक चेन त्रुटि से शुरू करें। निरस्त का अर्थ वर्तमान निरसन जानकारी प्राप्त नहीं हो सकती से भिन्न है। समाप्ति और अविश्वसनीय जारीकर्ता फिर अन्य समस्याएँ हैं। केवल पुनर्प्राप्ति विफलता ही स्टेटस URL तक गुम मार्ग का पता लगाने की माँग करती है।

उस विफलता के लिए तीन चीज़ें एक साथ पहचानें: जो URL प्राप्त किया जा रहा है, जो घटक प्राप्ति कर रहा है और उसकी प्रक्रिया पहचान। आपके इंटरैक्टिव खाते के अंतर्गत ब्राउज़र द्वारा URL सफलतापूर्वक खोलना यह सिद्ध नहीं करता कि कोई सेवा उसी प्रॉक्सी पर प्रमाणित हो सकती है।

यदि पहचाना गया घटक WinHTTP का उपयोग करता है, तो उस पर लागू नीति की जाँच करें। स्थिर प्रॉक्सी कॉन्फ़िगरेशन और प्रति-URL स्वचालित प्रॉक्सी मूल्यांकन अलग-अलग तंत्र हैं। इच्छित खाते के लिए समर्थित कॉन्फ़िगरेशन लागू करें; ब्राउज़र सेटिंग्स की नकल करना या असंबंधित रनटाइम बदलना वास्तविक प्राप्ति को अछूता छोड़ सकता है।

.NET में चेन नीति पर UrlRetrievalTimeout ऑनलाइन सत्यापन या CRL पुनर्प्राप्ति के लिए प्रतीक्षा नियंत्रित करता है। सामान्य HTTP प्रतिक्रिया टाइमआउट बढ़ाने से वही टाइमर नहीं बढ़ता, और पुनर्प्राप्ति टाइमर बढ़ाने से प्रॉक्सी क्रेडेंशियल या मार्ग नहीं मिलता।

HTTPS प्रॉक्सी इस निर्भरता को गंतव्य TLS से भी पहले दृश्यमान बना सकता है: प्रॉक्सी कनेक्शन पर भरोसा अपने आप में निरसन जानकारी की पुनर्प्राप्ति माँग सकता है। उस चरण पर समर्थित पुनर्प्राप्ति पहुँच और भरोसा व्यवस्था बहाल करें। निरसन जाँच अक्षम करने से प्रमाणपत्र नीति बदलती है; यह विफल पुनर्प्राप्ति बहाल नहीं करती।