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 मा निर्भर हुने ठाउँमा, नयाँ प्रमाणपत्रका वितरण बिन्दुहरू समाधान हुन्छन् र सोध्ने साथीहरूले उत्तरदातासम्म पुग्न सक्छन् भनी जाँच्नुहोस्।

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