प्रमाणपत्रे त्यांच्या वैधता कालावधीत असू शकतात, तर 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 किंवा प्रॉक्सीकडे. दोन्ही निकाल ठेवा, कारण एक यशस्वी पुनर्प्राप्ती संपूर्ण साखळी वापरण्यायोग्य आहे हे सिद्ध करत नाही. उदाहरणातील होस्ट आणि मार्ग प्रमाणपत्रात सापडलेल्या वितरण बिंदूने बदला.

गहाळ डेटा रद्द स्थितीपासून वेगळा करा

चार निकाल बाहेरून सारखे दिसतात: बिंदू पोहोचेच्या बाहेर आहे, यादी जुनी आहे, यादीवर चुकीच्या जारीकर्त्याची स्वाक्षरी आहे, किंवा प्रमाणपत्र खरोखर रद्द झाले आहे. फक्त शेवटचा स्थिती-निकाल आहे, आणि फक्त तोच प्रवेश काढण्याचे समर्थन करतो. कॅशिंग चित्र अधिक गुंतागुंतीचे करते, कारण आधी आणलेला डेटा पुढील रीफ्रेशपर्यंत तुटलेला प्रकाशन मार्ग लपवू शकतो. रद्द करण्याची तपासणी बंद करणे, असंबंधित प्रमाणपत्रे हटवणे किंवा गेटवे रीबूट करणे, हे सर्व निदानाच्या जागी क्रियाकलाप ठेवतात.

दुरुस्तीनंतर नवीन प्रमाणीकरण सक्तीने करा आणि इच्छित स्थिती पुनर्प्राप्ती यशस्वी आहे याची खात्री करा. जिथे नियंत्रित चाचणी ओळख आहे तिथे ती अजूनही नाकारली जाते याची खात्री करा, कारण तपासणी काढून मिळणारी उपलब्धता दुरुस्ती नाही.

संबंधित लेख