VPN प्रमाणपत्र का नवीनीकरण बिना उसकी पहचान बदले

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

तीन शर्तें नवीनीकरण का स्वरूप तय करती हैं

तीन शर्तें ये हैं कि क्या कोई चीज़ लीफ़ को पिन करती है, क्या श्रृंखला बदलती है, और नाम को और कौन मान्य करता है। इनका उत्तर CA की सुविधा के बजाय क्लाइंट के पक्ष से दें, क्योंकि रात के तीन बजे विफल होने वाला क्लाइंट ही होता है।

अपने पास मौजूद प्रमाणपत्र की जाँच से शुरू करें। openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName विषय, जारीकर्ता, वैधता विंडो और वे नाम छापता है जिनके लिए प्रमाणपत्र वास्तव में मान्य है। वही अंतिम फ़ील्ड सबसे महत्वपूर्ण है और सबसे अधिक मान लिया जाता है: ऐसा नवीनीकरण अनुरोध जो क्लाइंट के भरोसे वाले SAN को छोड़ देता है, तकनीकी रूप से मान्य पर कार्यात्मक रूप से गलत प्रमाणपत्र बनाता है। पुराने प्रमाणपत्र से SAN सूची को अनुरोध में कॉपी करें, स्मृति से फिर से टाइप करने के बजाय।

शर्त एक: क्या कोई चीज़ लीफ़ को पिन करती है

यदि क्लाइंट किसी अनुरक्षित CA पर भरोसा करते हैं और नाम को मान्य करते हैं, तो नई कुंजी के साथ लीफ़ नवीनीकरण उनके लिए अदृश्य है। यदि कोई क्लाइंट लीफ़ प्रमाणपत्र, उसकी फ़िंगरप्रिंट या उसकी सार्वजनिक कुंजी को पिन करता है, तो प्रतिस्थापन कठोर कटओवर वाला समन्वित परिवर्तन है, क्योंकि पुराना पिन नए प्रमाणपत्र को मान्य नहीं कर सकता।

कुछ भी ऑर्डर करने से पहले पता लगाएँ कि आप किस स्थिति में हैं। जिस पिन को किसी ने दर्ज नहीं किया, वह टूटने पर भी पिन ही रहता है।

शर्त दो: पिन और श्रृंखला की तुलना करें

फ़िंगरप्रिंट पिन को जाँचने योग्य बनाते हैं: पुराने और नए प्रमाणपत्र पर openssl x509 -noout -fingerprint -sha256 -in server.crt, और सार्वजनिक कुंजियों की तुलना के लिए openssl x509 -noout -pubkey। यदि क्लाइंट कॉन्फ़िगरेशन, मोबाइल प्रोफ़ाइल या किसी उपकरण का भरोसा भंडार इनमें से कोई भी मान रखता है, तो आपके पास पिन है। मोबाइल VPN प्रोफ़ाइल छिपने की आम जगह हैं, क्योंकि प्रोफ़ाइल एक बार वितरित होती है और फिर कभी जाँची नहीं जाती।

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

सर्वर वास्तव में जो श्रृंखला भेजता है उसे openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts से जाँचें, और openssl verify -CAfile ca.pem -untrusted chain.pem server.crt से स्थानीय रूप से सत्यापित करें। परिवर्तन से पहले ऐसा करने से आपको बाद में तुलना के लिए आधार रेखा मिलती है।

शर्त तीन: नाम को और कौन मान्य करता है

VPN कॉन्सेंट्रेटर, लोड बैलेंसर, मॉनिटरिंग प्रोब, RADIUS या SAML एकीकरण और मोबाइल प्रोफ़ाइल में से हर एक अपेक्षित नाम या भरोसा एंकर की अपनी प्रतिलिपि रख सकता है। नवीनीकरण वह क्षण है जब वे प्रतिलिपियाँ अलग हो जाती हैं, क्योंकि प्रमाणपत्र बदलता है और प्रतिलिपियाँ नहीं।

परिवर्तन से पहले हर उपभोक्ता की सूची बनाएँ और हर एक के लिए तय करें कि उसे अद्यतन चाहिए या नहीं। जिसे आप भूलते हैं वही आपको बुलाता है।

एक समय जाल भी है। समाप्ति के साथ-साथ वैधता की शुरुआत भी देखें, क्योंकि बाद में सक्रियण के लिए तैयार किया गया प्रमाणपत्र बहुत जल्दी स्थापित किए जाने पर अस्वीकार कर दिया जाता है, और त्रुटि तैयारी की समस्या के बजाय घड़ी की समस्या जैसी दिखती है। तैनात करने से पहले नई फ़ाइल पर openssl x509 -noout -dates दो सेकंड की जाँच है। एक समर्थित रिकवरी पथ और ज्ञात-अच्छा कॉन्फ़िगरेशन भी रखें, ताकि गलत होने वाला नवीनीकरण पिछले प्रमाणपत्र और कुंजी को पुनर्स्थापित करके उलटा जा सके।

तैनात करें, नए प्रमाणीकरण से सत्यापित करें, फिर हटाएँ

स्थापित टनल उस सत्यापन को दर्शाती है जो इसे बनाते समय हुआ था, इसलिए यह स्वस्थ दिख सकती है जबकि हर नया कनेक्शन विफल होता है। क्लाइंट जो वास्तविक सेवा नाम उपयोग करते हैं उसी के साथ नए प्रमाणीकरण से परीक्षण करें।

उपयोगकर्ता के लिए महत्वपूर्ण एप्लिकेशन-स्तर की जाँच पूरी करें, और श्रृंखला वितरण की पुष्टि सर्वर के बजाय क्लाइंट के दृष्टिकोण से करें। संक्रमण को शांत रखने के लिए नाम या प्रमाणपत्र जाँचों को दबाएँ नहीं; इससे अस्थायी संगतता समस्या स्थायी हो जाती है।

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