प्रमाणपत्र निरस्तीकरण विफल: कौन-सा होस्ट कहाँ नहीं पहुँचता

प्रमाणपत्र अपनी वैधता अवधि के भीतर हो सकते हैं, जबकि VPN अभी भी प्रमाणीकरण विफलता की सूचना देता है, और कोई निष्कर्ष निकालता है कि प्रमाणपत्र निरस्त हो गया है। ये तीन अलग तथ्य हैं। निरस्तीकरण डेटा उसी डिवाइस को लाना होता है जो सत्यापन करता है, और वह भी प्रमाणपत्र के भीतर ही नामित प्रकाशन बिंदु से। जब वह डिवाइस उस बिंदु तक नहीं पहुँच पाता, तो जाँच ऐसे कारणों से विफल होती है जिनका प्रमाणपत्र की स्थिति से कोई संबंध नहीं है।

पुनर्प्राप्ति पथ सत्यापनकर्ता के पास है

सत्यापनकर्ता की पहचान से शुरू करें। जब लैपटॉप गेटवे का प्रमाणपत्र जाँचता है, तो पुनर्प्राप्ति लैपटॉप करता है; जब गेटवे क्लाइंट प्रमाणपत्र जाँचता है, तो वह गेटवे करता है। बैक-एंड प्रमाणीकरण सेवा अपनी अलग नेटवर्क स्थिति वाला तीसरा सत्यापनकर्ता जोड़ सकती है। हर एक का इंटरनेट तक अलग मार्ग और अलग प्रॉक्सी कॉन्फ़िगरेशन होता है। किसी व्यवस्थापक के वर्कस्टेशन पर एकत्र किए गए साक्ष्य DMZ के भीतर के सर्वर के बारे में कुछ नहीं बताते।

कुछ भी बदलने से पहले प्रमाणपत्र, सत्यापनकर्ता, प्रयास का समय और सटीक स्थिति कोड लिख लें।

प्रमाणपत्र से प्रकाशन बिंदु पढ़ें

प्रमाणपत्र बताता है कि उसकी स्थिति कहाँ रहती है। CA पता अनुमान लगाने के बजाय वे फ़ील्ड पढ़ें।

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

पहला एक्सटेंशन CRL वितरण बिंदुओं की सूची देता है, और दूसरा प्राधिकरण-सूचना तक पहुँच के तरीकों की, जो OCSP स्थिति और जारीकर्ता प्रमाणपत्र की पुनर्प्राप्ति को कवर कर सकते हैं। ये अलग तंत्र हैं, और OCSP उत्तरदाता CRL फ़ाइल नहीं है। प्रकाशन होस्ट अक्सर CA मशीन नहीं बल्कि साधारण वेब सर्वर होता है, क्योंकि ऑफ़लाइन जारीकर्ता ऐसा CRL हस्ताक्षरित कर सकता है जिसे कोई दूसरा सर्वर वितरित करता है। इसलिए CA तक पहुँच के रूप में वर्णित फ़ायरवॉल नियम लागू करने या समीक्षा करने के लिए बहुत अस्पष्ट है।

उसी डिवाइस से पुनर्प्राप्ति जाँचें जो सत्यापन करता है

पुनर्प्राप्ति परीक्षण उसी वातावरण में चलाएँ जो वास्तव में सत्यापन करता है, स्वीकृत प्रमाणपत्र सामग्री के साथ और निजी कुंजियों के बिना।

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil चलाना श्रृंखला का सत्यापन करता है और बताता है कि कौन-सी URL पुनर्प्राप्तियाँ सफल या असफल रहीं, जबकि curl कॉल उसी होस्ट से एक प्रकाशन पता जाँचता है और केवल स्थिति कोड लौटाता है। पहुँच योग्य पते से असफल पुनर्प्राप्ति सामग्री या हस्ताक्षर की समस्या की ओर संकेत करती है; कनेक्शन त्रुटि रूटिंग, DNS या प्रॉक्सी की ओर। दोनों परिणाम रखें, क्योंकि एक सफल पुनर्प्राप्ति यह सिद्ध नहीं करती कि पूरी श्रृंखला उपयोगी है। उदाहरण का होस्ट और पथ बदलकर प्रमाणपत्र में मिला वितरण बिंदु रखें।

अनुपस्थित डेटा को निरस्त स्थिति से अलग करें

चार परिणाम बाहर से एक जैसे दिखते हैं: बिंदु पहुँच से बाहर है, सूची पुरानी है, सूची पर गलत जारीकर्ता के हस्ताक्षर हैं, या प्रमाणपत्र वास्तव में निरस्त है। केवल अंतिम ही स्थिति-परिणाम है, और केवल वही पहुँच हटाने का औचित्य देता है। कैशिंग तस्वीर को और जटिल बनाती है, क्योंकि पहले लाया गया डेटा अगली रीफ़्रेश तक टूटे प्रकाशन पथ को छिपा सकता है। निरस्तीकरण जाँच बंद करना, असंबंधित प्रमाणपत्र हटाना या गेटवे रीबूट करना, सब निदान के बदले गतिविधि रखते हैं।

सुधार के बाद नया प्रमाणीकरण बाध्य करें और पुष्टि करें कि इच्छित स्थिति पुनर्प्राप्ति सफल है। जहाँ नियंत्रित परीक्षण पहचान मौजूद है, वहाँ पुष्टि करें कि उसे अब भी अस्वीकार किया जाता है, क्योंकि जाँच को हटाने वाली उपलब्धता मरम्मत नहीं है।