CRL आणि OCSP प्रमाणपत्र तपासणीत प्रॉक्सी अपयशांचा मागोवा

वेबसाइटची विनंती तिच्या प्रॉक्सीपर्यंत पोहोचू शकते आणि तरीही अयशस्वी होऊ शकते, कारण प्रमाणपत्राच्या पडताळणीसाठी आणखी एक नेटवर्क विनंती आवश्यक असते. CRL किंवा OCSP पुनःप्राप्ती अ‍ॅप्लिकेशनच्या HTTP क्लायंटपेक्षा वेगळ्या खाते आणि प्रॉक्सी धोरण असलेल्या प्लॅटफॉर्म घटकातून होऊ शकते.

नेमक्या साखळी त्रुटीपासून सुरुवात करा. Revoked चा अर्थ सध्याची रद्दीकरण माहिती मिळवता येत नाही पेक्षा वेगळा आहे. कालबाह्यता आणि अविश्वसनीय जारीकर्ता हे पुन्हा वेगळे प्रश्न आहेत. फक्त पुनःप्राप्तीचे अपयश स्थिती URL कडे जाणारा गहाळ मार्ग शोधण्याची मागणी करते.

त्या अपयशासाठी तीन गोष्टी एकत्र ओळखा: मिळवला जाणारा URL, पुनःप्राप्ती करणारा घटक आणि त्याची प्रक्रिया ओळख. तुमच्या परस्परसंवादी खात्याखाली ब्राउझरने URL यशस्वीपणे उघडणे म्हणजे सेवा त्याच प्रॉक्सीवर प्रमाणित होऊ शकते असा पुरावा नाही.

ओळखलेला घटक WinHTTP वापरत असल्यास, त्यावर लागू धोरण तपासा. स्थिर प्रॉक्सी कॉन्फिगरेशन आणि URL-निहाय स्वयंचलित प्रॉक्सी मूल्यांकन या वेगवेगळ्या यंत्रणा आहेत. इच्छित खात्यासाठी समर्थित कॉन्फिगरेशन लागू करा; ब्राउझर सेटिंग्ज कॉपी करणे किंवा असंबंधित रनटाइम बदलणे हे प्रत्यक्ष पुनःप्राप्तीला स्पर्श न करता सोडू शकते.

.NET मध्ये, साखळी धोरणावरील UrlRetrievalTimeout ऑनलाइन पडताळणी किंवा CRL पुनःप्राप्तीसाठी प्रतीक्षा नियंत्रित करते. नेहमीच्या HTTP प्रतिसाद कालमर्यादेचा विस्तार तोच टाइमर वाढवत नाही, आणि पुनःप्राप्ती टाइमरचा विस्तार प्रॉक्सी क्रेडेन्शियल्स किंवा मार्ग देत नाही.

HTTPS प्रॉक्सी हे अवलंबित्व गंतव्य TLS च्या आधीच दृश्यमान करू शकते: प्रॉक्सी कनेक्शनवरील विश्वासालाच रद्दीकरण पुनःप्राप्तीची आवश्यकता असू शकते. त्या टप्प्यावर समर्थित पुनःप्राप्ती प्रवेश आणि विश्वास व्यवस्था पुनर्संचयित करा. रद्दीकरण तपासणी बंद करणे प्रमाणपत्र धोरण बदलते; ते अयशस्वी पुनःप्राप्ती पुनर्संचयित करत नाही.