प्रमाणपत्र वैध होने पर भी नए VPN लॉगिन विफल होते हैं: CRL जाँचें

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

दोनों समय-सारणियों को अलग करना ही पूरा निदान है, और यह बदल देता है कि सुधार कैसा होना चाहिए।

दो घड़ियाँ, और उनमें से केवल एक ही प्रमाणपत्र है

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

दोनों वस्तुओं के स्वामी भी अलग हैं: प्रमाणपत्र उस CA से आता है जिसने उसे जारी किया, जबकि सूची समय-सारणी के अनुसार उसी CA को चलाने वाले द्वारा बनाई जाती है। उपयोगकर्ता इसे ताज़ा नहीं कर सकता, और प्रमाणपत्र फिर से जारी करने से इसे बढ़ाया नहीं जा सकता।

वह सूची पढ़ें जो सेवा वास्तव में लोड करती है

उस फ़ाइल से नहीं, जिसकी आप अपेक्षा करते हैं, चल रहे कॉन्फ़िगरेशन से शुरू करें। crl-verify का पथ निरपेक्ष हो सकता है, प्रोफ़ाइल के सापेक्ष हो सकता है, या किसी इमेज में जड़ी हुई प्रति हो सकता है, और सत्यापनकर्ता उसी प्रति को पढ़ता है। इसे उसके स्थान पर openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate से जाँचें और तिथियों की तुलना सर्वर की घड़ी से करें।

फिर पुष्टि करें कि फ़ाइल वास्तव में वही है जो उपयोग में है: openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout से उसका हस्ताक्षर जाँचें, जो फ़ील्ड चुपचाप छापने के बजाय सत्यापन परिणाम बताता है। किसी दूसरे CA द्वारा हस्ताक्षरित सूची, या दूसरी निर्देशिका में छोड़ी गई पुरानी प्रति, ठीक समाप्त सूची की तरह विफल हो जाती है।

शून्य से नहीं, निरसन डेटाबेस से फिर से बनाएँ

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

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

जहाँ सत्यापनकर्ता देखता है वहीं परिनियोजित करें

नई सूची को उस पथ पर प्रतिलिपि बनाएँ जिसे सेवा पढ़ती है, स्वामित्व और मोड ऐसे सेट करें कि सेवा खाता इसे पढ़ सके पर अन्य नहीं, और प्रलेखित व्यवहार के अनुसार पुनः लोड या पुनः आरंभ करें। यदि डेमन प्रारंभ पर सूची कैश करता है, तो पुनः लोड के बिना फ़ाइल बदलने से चल रही प्रक्रिया को कुछ भी पता नहीं चलेगा। पुनः लोड के बाद प्रक्रिया जो समय-चिह्न बताती है उसे सत्यापित करें।

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

अगली समय-सीमा बीतने से पहले उसे दृश्य बनाएँ

लंबा प्रकाशन अंतराल प्रक्रिया बनाए बिना इस घटना की आवृत्ति कम करता है। ऑपरेटर की नीति से अंतराल चुनें, फिर फिर से बनाने और परिनियोजित करने के लिए पर्याप्त समय के साथ परिनियोजित सूची के अगले-अद्यतन फ़ील्ड पर चेतावनी दें। परिनियोजित प्रति पर चेतावनी दें, CA होस्ट पर नहीं, क्योंकि परिनियोजित प्रति ही विफल होती है।

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