गलत VPN प्रमाणपत्र रद्द कर दिया? रिकवरी विकल्प और सीमाएँ

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

प्रमाणपत्र की पहचान करें, व्यक्ति की नहीं

सामान्य नाम दोहराए जाते हैं। पिछली तिमाही में फिर से नामांकित उपयोगकर्ता के पास एक ही CN और अलग क्रमिक संख्याओं वाले दो प्रमाणपत्र हो सकते हैं, और एक को रद्द करने से दूसरा काम करता रहता है। पहले सटीक वस्तु निर्धारित करें:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

क्रमिक संख्या, जारीकर्ता, रद्दीकरण की तिथि और CRL में दर्ज कारण लिखें। फिर पुष्टि करें कि कौन-से उपकरण वह क्रमिक संख्या प्रस्तुत करते हैं, क्योंकि रद्द किया गया प्रमाणपत्र अभी भी लैपटॉप, फ़ोन और अतिरिक्त राउटर पर स्थापित हो सकता है, और केवल एक तक पहुँचने वाला प्रतिस्थापन दूसरी घटना पैदा करता है।

एक तेज़ व्यवहार जाँच कुछ भी बदले बिना स्थिति की पुष्टि करती है:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

अगर यह प्रमाणपत्र को रद्द बताती है, तो CRL और क्लाइंट सहमत हैं; अगर यह साफ़ सत्यापित होता है, तो आपके हाथ में मौजूद क्लाइंट रद्द वाला नहीं है, और खोज जारी रहती है।

जाँचें कि CA ने होल्ड या स्थायी रद्दीकरण का उपयोग किया

RFC 5280 certificateHold को अस्थायी स्थिति और removeFromCRL को उसे मुक्त करने वाला संकेत परिभाषित करता है। वह जीवनचक्र वास्तविक है, लेकिन यह सामान्य अनडू बटन नहीं है। कारण कोड पढ़ने से पता चलता है कि जारीकर्ता ने कभी मुक्ति का समर्थन करने का इरादा किया था या नहीं।

जाल यह मानना है कि अस्थायी इरादे का अर्थ अस्थायी रिकॉर्ड है। अगर CA प्रविष्टि में keyCompromise या cessationOfOperation है, तो बटन दबाने वाले व्यक्ति का इरादा जो भी रहा हो, प्रमाणपत्र स्थायी रूप से रद्द है। इसके विपरीत, जो CA होल्ड-मुक्ति लागू नहीं करता, उस पर certificateHold चिह्नित प्रविष्टि व्यवहार में स्थायी है, क्योंकि कुछ भी कभी मुक्ति प्रकाशित नहीं करेगा।

OpenSSL-आधारित CA इस सीमा को दर्शाते हैं। ca कमांड -crl_reason मान स्वीकार करता है, जिनमें certificateHold और removeFromCRL शामिल हैं, लेकिन यह डेल्टा CRL उत्पन्न नहीं करता — OpenSSL CA दस्तावेज़ अपने CRL आउटपुट के लिए यह सीमा बताते हैं। जो पूर्ण CRL क्रमिक संख्या को महज़ छोड़ देता है, वह "यह प्रविष्टि मुक्त है" कहने वाले डेल्टा से भिन्न प्रकाशन मॉडल है, इसलिए OpenSSL-आधारित VPN CA में removeFromCRL चिपकाने से मानकों द्वारा परिभाषित मुक्ति उत्पन्न नहीं होती।

अगर कुंजी उजागर हुई हो सकती है, तो उसे बदलें

रद्द किया गया प्रमाणपत्र यह घोषणा है कि इस कुंजी पर अब भरोसा नहीं किया जा सकता। अगर रद्दीकरण सारतः सही था — लैपटॉप खो गया, कुंजी साझा डिस्क पर कॉपी हुई, निजी कुंजी टिकट में चिपकाई गई — तो वही प्रमाणपत्र बहाल करना ऐसे सुरक्षा निर्णय को उलट देता है जो इरादे के अनुसार काम कर रहा था।

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

पुराने को बहाल करने का सुविधा तर्क वास्तविक है, लेकिन उसका उत्तर स्पष्ट रूप से दिया जाना चाहिए, चुपचाप नहीं। "उपयोगकर्ता को आज पहुँच चाहिए" जारी करने को तेज़ करने का कारण है, उस कुंजी का रद्दीकरण वापस लेने का कारण नहीं जिसका आप हिसाब नहीं दे सकते।

अगर यह प्रशासनिक गलती थी, तो नियंत्रण में बदलें

जब रद्दीकरण महज़ गलत था और कुंजी कभी उजागर नहीं हुई, तो मरम्मत अब भी संपादन नहीं बल्कि नियंत्रित प्रतिस्थापन है। जारीकर्ता की समर्थित प्रक्रिया का उपयोग करें, क्रमिक संख्या और जारी करने का इतिहास अक्षुण्ण रखें, और दो लुभावने शॉर्टकट से बचें: index.txt में स्थिति अक्षर को R से वापस V में बदलना, और जारी करने की पंक्ति हटाना ताकि नया प्रमाणपत्र क्रमिक संख्या का पुनः उपयोग कर सके।

OpenSSL CA में डेटाबेस टैब-पृथक होता है और गलत पढ़ना आसान है, जो हाथ से संपादन को आकर्षक बनाता है:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

इसे पढ़ें, इसे लिखें नहीं। फ़ाइल संपादित करने से बिना किसी ऑडिट ट्रेल के अगला CRL बदल जाता है, और मूल पंक्ति रखने वाला कोई भी दूसरा CA इंस्टेंस या बैकअप बाद में इससे असहमत होगा।

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

नए प्रवेश की पुष्टि करें और रिकॉर्ड रखें

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

जो हुआ उसे ताज़ा रहते हुए दर्ज करें: कौन-सी क्रमिक संख्या रद्द हुई, किसने, किस कारण से, कौन-सा प्रतिस्थापन जारी हुआ, और CRL कब पुनः प्रकाशित हुआ। वही रिकॉर्ड अगली रद्दीकरण समीक्षा को संभव बनाता है, और यह भी प्रमाण है कि गलती छिपाई नहीं बल्कि संभाली गई।

भविष्य में छोटे निलंबनों के लिए, अगर परिनियोजन में हो तो प्रवेश-विराम तंत्र का उपयोग करें — पहचान परत पर निष्क्रिय खाता, हटाई गई समूह सदस्यता, रोकी गई क्लाइंट प्रोफ़ाइल। यह अस्थायी नीति निर्णय को इस प्रश्न से अलग रखता है कि जारी प्रमाणपत्र अभी भी भरोसेमंद है या नहीं, और पहली बार ठीक यही अंतर खो गया था।