प्रमाणपत्र रद्द जाँच असफल: कुन होस्टले के पुग्न सक्दैन

प्रमाणपत्रहरू आफ्नो वैधता अवधिभित्रै रहन सक्छन् तर 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 वा प्रोक्सी देखाउँछ। दुवै नतिजा राख्नुहोस्, किनभने एउटा सफल ल्याइले पूरै चेन प्रयोगयोग्य छ भनी प्रमाणित गर्दैन। नमुना होस्ट र पथलाई प्रमाणपत्रमा भेटिएको वितरण बिन्दुले बदल्नुहोस्।

हराएको जानकारी र रद्द स्थिति छुट्याउनुहोस्

बाहिरबाट चार नतिजा उस्तै देखिन्छन्: बिन्दु पुग्न नसकिने, सूची पुरानो, सूची गलत जारीकर्ताद्वारा हस्ताक्षरित, वा प्रमाणपत्र साँच्चै रद्द। अन्तिम मात्र स्थिति नतिजा हो, र त्यसले मात्र पहुँच हटाउनु जायज ठहराउँछ। क्यासिङले चित्र अझ जटिल बनाउँछ, किनभने पहिले ल्याइएको जानकारीले अर्को रिफ्रेससम्म बिग्रिएको प्रकाशन मार्ग लुकाउन सक्छ। रद्द जाँच बन्द गर्नु, असम्बन्धित प्रमाणपत्र मेट्नु वा गेटवे रिबुट गर्नु सबै निदानको सट्टा गतिविधि मात्र हुन्।

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