नवीकरणपछि आधा वातावरण फेरि जोडिन्छ र तीन उपकरण अस्वीकार गर्छन्, प्रत्येक गेटवेको पहिचानबारे चेतावनीसहित। नवीकरण आफैं सामान्य काम हो। ती तीन उपकरणसँग पुरानो वस्तुको पिन छ, र पिन कुनै 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 विश्वासभन्दा कमजोर डिजाइन हो।

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

सम्बन्धित लेखहरू