जब आप VPN प्रमाणपत्र प्राधिकरण बदलते हैं तो क्या होता है

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

एक प्रतिस्थापन, दो अलग बदलाव

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

अधिकांश VPN परिनियोजन दोनों दिशाओं में सत्यापन करते हैं। क्लाइंट गेटवे के प्रमाणपत्र को प्रमाणित करता है, और गेटवे क्लाइंट के प्रमाणपत्र को। जो परिवर्तन केवल क्लाइंट बंडल को ताज़ा करता है वह सर्वर को हर उस क्लाइंट को अस्वीकार करने देता है जो अब भी पुराने CA की पहचान प्रस्तुत करता है, और उल्टा भी उतना ही सामान्य है। पहले प्रवर्तन बिंदुओं की सूची बनाएँ: क्लाइंट भरोसा भंडार, गेटवे की ca फ़ाइल, उसके सामने TLS समाप्त करने वाला कोई भी प्रॉक्सी, और वह जाँच जो अंतिम बिंदु को बाहर से परखती है।

सत्यापक क्या जाँचता है, क्रम में

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

उस यात्रा को ऑफ़लाइन दोहराने के लिए, -CAfile को ठीक उसी बंडल की ओर इंगित करें जिसे आप परिनियोजित करेंगे, सिस्टम भंडार की ओर नहीं। अन्यथा आप बदलाव नहीं, होस्ट परख रहे हैं:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

यह कमांड केवल गेटवे के HTTPS प्रशासन पृष्ठ जैसे साधारण TLS श्रोता के विरुद्ध काम करता है; OpenVPN का नियंत्रण चैनल TLS से पहले आता है, इसलिए s_client सुरंग का हैंडशेक नहीं देख सकता।

उन त्रुटियों के पीछे के पथ-निर्माण नियम RFC 5280 अनुभाग 6 में हैं। वे उन विफलताओं को समझाते हैं जो अन्यथा मनमानी लगती हैं: कोई भूला हुआ समाप्त मध्यवर्ती, ऐसा प्रमाणपत्र जिसका कुंजी उपयोग हस्ताक्षर को मना करता है, या ऐसा नाम प्रतिबंध जो आपके परीक्षण वाले होस्ट को बाहर रखता है।

पुरानी सुरंग क्यों काम करती रहती है

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

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

स्थिर-कुंजी परत को इससे अलग रखें। tls-auth नियंत्रण चैनल में HMAC जोड़ता है, tls-crypt उसे एन्क्रिप्ट और प्रमाणित करता है, और इनमें से कोई भी प्रमाणपत्र सामग्री नहीं ले जाता, इसलिए किसी भी एक का रोटेशन अपनी विफलता-विधि वाला अलग बदलाव है। जो परिनियोजन दोनों को मिला देते हैं वे ऐसे क्लाइंट पर पहुँचते हैं जिसकी स्थिर कुंजी ठीक है, प्रमाणपत्र पुराना है और त्रुटि संदेश किसी का भी उल्लेख नहीं करता।

विषय नाम के पुनः उपयोग का जाल

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

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

ऐसा रोटेशन जो नेटवर्क न गिराए

नियोजित प्रतिस्थापन के लिए एक ही चरण में बदलने के बजाय सीमित अवधि के लिए दोनों एंकर स्वीकार करें। नया CA और उसके मध्यवर्ती जारी करें, नया एंकर हर सत्यापक के बंडल में पुराने के साथ रखें, और उसके बाद ही उससे सहकर्मी प्रमाणपत्र जारी करना शुरू करें। पुरानी पहचान वाले सहकर्मी पुराने एंकर के विरुद्ध सत्यापित होते हैं; नए नए एंकर के विरुद्ध काम करते हैं।

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

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

परिणाम सत्यापित करें, फ़ाइल सूची नहीं

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

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

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