नूतनीकृत VPN प्रमाणपत्र: काही क्लायंट अजूनही ते नाकारतात

नूतनीकरणानंतर अर्धा परिसर पुन्हा जोडतो आणि तीन उपकरणे नाकारतात, प्रत्येक गेटवेच्या ओळखीबद्दल चेतावणीसह। नूतनीकरण स्वतः नित्याचे काम आहे। त्या तीन उपकरणांकडे जुन्या वस्तूचे पिन आहे, आणि पिन ही CA सूची, नाव तपासणी किंवा ट्रस्ट स्टोअर नोंद नाही। कोणत्याही क्लायंटला स्पर्श करण्यापूर्वी तीनही यंत्रणांची तुलना करा।

एक नूतनीकरण, दोन वर्तन

पुन्हा जोडणाऱ्या क्लायंटकडे अजूनही उत्तीर्ण होणारा विश्वासाचा निर्णय आहे, आणि नाकारणाऱ्यांकडे नवे प्रमाणपत्र पूर्ण न करणारी आवश्यकता आहे। हा फरक माहिती आहे, गोंगाट नाही। अपयशी क्लायंटचा संदेश नेमका वाचा। नावाची जुळणी न होणे, अज्ञात जारीकर्ता आणि बदललेला फिंगरप्रिंट या तीन वेगळ्या निवाड्या आहेत, आणि फक्त शेवटचा पिनकडे निर्देश करतो।

अपयशी क्लायंटने कोणता प्रोफाइल निवडला हेही तपासा। स्वतःच्या स्टोअरमध्ये राहणारी आयात केलेली प्रत, प्रशासक मूळ फाइल दुसरीकडे संपादित करतो तेव्हा बदलत नाही।

नूतनीकरण वस्तू बदलते, फक्त तारीख नाही

फिंगरप्रिंट एन्कोड केलेल्या प्रमाणपत्रातील सामग्री ओळखते। नूतनीकरण नवे प्रमाणपत्र तयार करते, म्हणून विषयाचे नाव आणि सार्वजनिक की समान राहिली तरी फिंगरप्रिंट बदलतो। CA वर विश्वास ठेवून नाव पडताळणाऱ्या क्लायंटसाठी हे अपेक्षित आणि निरुपद्रवी आहे। नेमके एकच प्रमाणपत्र स्वीकारण्यासाठी संरचित क्लायंटसाठी हे घातक आहे, आणि ज्याच्या ट्रस्ट स्टोअरला नवा जारीकर्ता कधीच मिळाला नाही अशा क्लायंटसाठीही ते घातक आहे।

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

दुसरी ओळ वेगळ्या प्रश्नाचे उत्तर देते, की जोडी टिकली का। की पुन्हा वापरणारे नूतनीकरण ते मूल्य टिकवते आणि फक्त प्रमाणपत्र बदलते, आणि काहीच बदलले नाही असे प्रशासकाला वाटण्याची प्रेरणा देणारी तीच परिस्थिती आहे। तैनात केलेले प्रमाणपत्र तपासा, बिल्ड होस्टवरील नाही। रिपॉझिटरीतील फाइलची तुलना काय निर्माण झाले हे सिद्ध करते, श्रोता सध्या काय सादर करत आहे ते नाही।

क्लायंट काय पिन करत आहे ते वाचा

काही क्लायंट त्यांच्या प्रोफाइलमध्ये फिंगरप्रिंट ठेवतात आणि प्रत्येक कनेक्शनला तुलना करतात। इतर ते प्लॅटफॉर्म ट्रस्ट स्टोअरमध्ये साठवतात, आणि अजून काही फक्त CA वर अवलंबून असतात। प्रत्येक प्रकरणात दुरुस्ती वेगळी असते, म्हणून आधी यंत्रणा ओळखा।

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

पहिला आदेश पारंपरिक प्रोफाइलमधील पिन दाखवतो; दुसरा एंडपॉइंट सध्या खरोखर पुरवत असलेला फिंगरप्रिंट दाखवतो। हे दोन वेगळे असतील तर तुम्ही अंदाज न लावता बिघाड शोधला। नवे मूल्य तक्रार करणाऱ्या प्रत्येक क्लायंटमध्ये चिकटवू नका। जारीकर्त्यामुळे नाकारणारा क्लायंट नाकारतच राहील, आणि समस्या फिंगरप्रिंट नसतानाही ती होती असे तुम्ही स्वतःला शिकवाल।

प्रत्येक बॅकएंड पुरवत असलेल्या प्रमाणपत्राची तुलना करा

मधूनमधून मिळणारे निकाल सहसा एकापेक्षा जास्त एंडपॉइंट दर्शवतात, आणि एका नोडवर लागू केलेले नूतनीकरण बाकीच्यांना जुनी वस्तू सादर करू देतो। प्रत्येक बॅकएंडची सामायिक नावाने नाही तर पत्त्याने तुलना करा।

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

एक नोड मागे असलेला पूल, दुसऱ्या प्रयत्नात जोडणाऱ्या आणि पहिल्यात अपयशी होणाऱ्या क्लायंटचे स्पष्टीकरण देतो। वापरकर्ते तक्रार करत असताना उत्तीर्ण होणाऱ्या देखरेख तपासणीचेही ते स्पष्टीकरण देते। आधी मागेपण दुरुस्त करा। प्रत्येक नोड नवे प्रमाणपत्र पुरवण्यापूर्वी विश्वास संरचना रोल केल्यास काहीही चालत नसलेली खिडकी तयार होते, आणि नंतर रोल केल्यास क्लायंट अप्रत्याशितपणे अपयशी होत राहतात।

व्यवस्थापित मार्गाने विश्वास बदला

कुठेही स्वीकारण्यापूर्वी आधीच विश्वासार्ह प्रशासकीय माध्यमातून बदलाची पुष्टी करा। विश्वासार्ह कालबाह्यता तारीख मालकीचा पुरावा नाही। व्यवस्थापित संरचना तिच्या मालक असलेल्या प्रक्रियेद्वारे अद्ययावत करा, स्वीकार्य ओळखींच्या नियोजित ओव्हरलॅपसह, आणि तैनातीला आवश्यक असलेली नाव पडताळणी टिकवा। नाव तपासणीशिवाय पिन ही त्याने बदललेल्या CA विश्वासापेक्षा कमकुवत रचना आहे।

मग प्रत्येक क्लायंटसाठी पडताळा, जोडा, त्याने स्वीकारलेली ओळख पुष्टी करा, आणि आता तो विश्वास ठेवत असलेल्या प्रमाणपत्राची आवृत्ती नोंदवा। एकदा नाकारलेली चेतावणी पुढच्या नूतनीकरणाला परत येण्याची सवय असते।