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 बदलीपासून वेगळे ठेवा, जेणेकरून ग्राहकांना कारणाशिवाय नवीन जारीकर्त्यावर विश्वास ठेवण्यास सांगितले जाणार नाही।