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

पता करें कि वास्तव में कौन-सा प्रमाणपत्र समाप्त हो रहा है

एक परिनियोजन में सर्वर लीफ़ प्रमाणपत्र, क्लाइंट क्रेडेंशियल, एक या अधिक मध्यवर्ती प्रमाणपत्र और एक विश्वास एंकर होता है, और ये एक साथ समाप्त नहीं होते। त्रुटि में नामित प्रमाणपत्र और वह श्रृंखला पढ़ें जिसके साथ यह प्रस्तुत हुआ था, प्रोफ़ाइल निर्देशिका की पहली फ़ाइल नहीं। जो सर्वर लीफ़ साफ़ तौर पर नवीनीकृत होता है, वह भी विफल हो सकता है यदि उसके ऊपर का मध्यवर्ती प्रमाणपत्र समाप्त हो गया हो। कुछ भी बदलने से पहले प्रत्येक फ़ाइल का विषय, जारीकर्ता, not-after और परिनियोजन स्थान लिख लें।

विश्वास एंकर आमतौर पर सबसे लंबे समय तक जीने वाला ऑब्जेक्ट और सबसे कम संभावित कारण होता है।

जीवित सत्र तारीख़ से आगे क्यों टिक सकता है

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

तारीख़ को नए लॉगिन के लिए अंतिम तिथि और सत्र के जीवनकाल को उधार लिया समय मानें।

प्रमाणपत्र को दोष देने से पहले घड़ी जाँचें

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

बूट पर रीसेट होने वाली घड़ी उन विफलताओं की व्याख्या करती है जो बिजली कटने के बाद ही दिखती हैं।

जिस प्राधिकरण ने इसे जारी किया उसके माध्यम से नवीनीकरण करें

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

नई श्रृंखला पूरी तरह प्रकाशित करें, क्योंकि मध्यवर्ती के बिना लीफ़ आधा नवीनीकरण है जो केवल उन्हीं मशीनों पर काम करता है जिन्होंने इसे पहले से कैश कर रखा है।

नए लॉगिन से इसे सिद्ध करें, वापसी का रास्ता रखें

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

मौजूदा सत्र अब भी पहले की स्थिति दर्शा सकते हैं, इसलिए वे किसी भी दिशा में कुछ सिद्ध नहीं करते।

उस दिन मैं जो क्रम अपनाता हूँ

समाप्त होते ऑब्जेक्ट और उसकी श्रृंखला की पुष्टि करें, फिर घड़ियों की पुष्टि करें:

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

फिर नवीनीकरण करें, पूरी श्रृंखला परिनियोजित करें, नए लॉगिन से परीक्षण करें, और उसके बाद ही सफ़ाई करें। वैधता अवधियाँ और उनके मूल्यांकन के नियम RFC 5280 में परिभाषित हैं, और यदि आपकी निगरानी ने वास्तव में समाप्त होने वाले ऑब्जेक्ट पर नज़र रखी है तो तारीख़ कोई आश्चर्य नहीं है।

संबंधित लेख