तपाईंको VPN क्लाइन्टले प्रमाणपत्रमा भरोसा गर्नु अघि के जाँच्छ
प्रमाणपत्रको चेतावनीलाई तपाईंको क्लाइन्टले जाँच्ने चार ढोकाबाट गुजार्नुहोस्: CA मा भरोसा, शृंखला निर्माण, पीयरको नाम र उद्देश्य, र रद्द गर्ने नीति।
तपाईंको VPN क्लाइन्ट भन्छ कि प्रमाणपत्र प्रमाणित गर्न सकिएन, र संवाद त्यहीँ रोकिन्छ। फाइल छ, सर्भर चलिरहेको छ, र त्यही प्रोफाइल गत महिना अर्को ल्यापटपमा चलेको थियो। त्यो एक-लाइन चेतावनीमुनि क्लाइन्टले पीयर प्रमाणपत्रलाई चार ढोकाबाट गुजार्यो: तपाईंले कन्फिगर गरेको प्रमाणपत्र प्राधिकरणले हस्ताक्षर मार्गको जमानत दिन्छ, त्यो मार्ग प्राधिकरणसम्म पुग्छ, पीयरको नाम तपाईंले मागेको नाम हो, र प्रमाणपत्र अब यो उद्देश्यका लागि प्रयोगयोग्य छ। बन्द भएको ढोका खोज्नुहोस् र मर्मत सामान्यतया एउटा फाइल हो; त्यो चरण छोड्नुभयो भने दिउँसोभरि बन्डेल फेरि आयात गर्नुहुनेछ।
प्रोफाइल सम्पादन गर्नु अघि संवाद पढ्नुहोस्
प्रमाणपत्रका त्रुटिका शब्द तलको लाइब्रेरीले बनाउँछ, तपाईंले इन्स्टल गरेको VPN उत्पादनले होइन, त्यसैले ठ्याक्कै स्ट्रिङ तपाईंको पहिलो प्रमाण हो। «स्थानीय जारीकर्ताको प्रमाणपत्र लिन सकिएन» मार्ग वा भरोसा एङ्करतर्फ संकेत गर्छ। «प्रमाणपत्रको अवधि सकियो वा अझै वैध छैन» समयतर्फ संकेत गर्छ। «असमर्थित प्रमाणपत्र उद्देश्य» विस्तारित कुञ्जी प्रयोगतर्फ संकेत गर्छ। नामको अमिल्दोले कुन नाम चाहेको थियो भन्छ। चारमध्ये कुनै पनि क्लाइन्ट पुनःस्थापना गरेर सुधारिँदैन।
केही परिवर्तन गर्नु अघि लग स्तर बढाउनुहोस्। OpenVPN --verb 4 सँग चलाउँदा ह्यान्डशेक वरपर प्रमाणीकरण असफलता जनाउँछ, र strongSwan आफ्ना पहिचान र शृंखलाका निर्णयहरू charon लगमा लेख्छ। त्यसपछि तपाईं कुन प्रमाणपत्र जाँच्दै हुनुहुन्छ भनी निश्चित गर्नुहोस्, किनकि मानिसहरू सामान्यतया डिस्कको फाइल परीक्षण गर्छन् जबकि प्रोफाइलले पुरानो प्रतिलिपि भित्र राख्छ। प्रोफाइलले PEM ब्लक भित्र राख्दा भित्र राखिएको प्रमाणपत्र नै परीक्षण हुन्छ।
प्रमाणपत्र प्राधिकरणले पहिचानमा हस्ताक्षर गर्छ, अनुमतिमा होइन
प्राधिकरणसँग एउटा नाम र एउटा हस्ताक्षर कुञ्जी हुन्छ। यसले आफ्नै नीतिअनुसार सार्वजनिक कुञ्जीलाई त्यो नाममा बाँध्ने प्रमाणपत्र जारी गर्छ, साथै वैधता अवधि र प्रयोग प्रतिबन्ध जोडिएका हुन्छन्। तपाईंको क्लाइन्टलाई जारीकर्ता चिन्न प्राधिकरणको प्रमाणपत्र मात्र चाहिन्छ; यसलाई हस्ताक्षर कुञ्जी कहिल्यै चाहिँदैन, र त्यो कुञ्जी क्लाइन्टहरूलाई पठाउँदा परिनियोजनले भरोसा गर्ने जुनसुकै पहिचान बनाउने क्षमता तिनीहरूलाई दिन्थ्यो।
प्राधिकरणमा भरोसा गर्दा यसले हस्ताक्षर गरेको हरेक प्रमाणपत्र उम्मेदवार बन्छ, सही पीयर होइन। त्यही आन्तरिक CA को वेब सर्भर प्रमाणपत्र पनि उम्मेदवार हो। त्यसैले नाम र उद्देश्यका ढोका छन्, र त्यसैले सम्झौता भएको CA कुञ्जी कुनै एकल सर्भरभन्दा महत्त्वपूर्ण छ: यो प्राधिकरणले कहिल्यै जारी गरेको हरेक पहिचानसम्म पुग्छ। प्रत्येक यन्त्रका लागि छुट्टै क्लाइन्ट प्रमाणपत्र दिनुहोस्, ताकि हराएको ल्यापटप पूरै परिनियोजनको कुञ्जी पुनर्निर्माण होइन, एक रद्दीकरण होस्।
क्लाइन्टले बनाउन खोजेको मार्ग फेरि बनाउनुहोस्
मार्ग पीयर प्रमाणपत्रबाट सुरु भई शून्य वा बढी मध्यस्थ प्रमाणपत्रहरू हुँदै तपाईंको भरोसा भण्डारको मूलसम्म पुग्छ। हराएको मध्यस्थ प्रमाणपत्र सबैभन्दा सामान्य शृंखला खराबी हो, र क्लाइन्टकोतर्फबाट यो अविश्वसनीय मूल जस्तै देखिन्छ। पहिले पात पढ्नुहोस्, त्यसपछि तपाईंले पठाउन लागेको सामग्रीबाट OpenSSL ले मार्ग बनाओस्।
openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crtशून्य निकास स्थिति भनेको त्यी फाइलहरूबाट मार्ग बन्यो; असफलताले पुग्न नसकेको प्रमाणपत्रको नाम भन्छ। openssl verify सफल हुँदा पनि क्लाइन्टले अस्वीकार गरेमा फरक सर्भरले वास्तवमा के पठाउँछ वा प्रोफाइलले कुन भरोसा फाइल लोड गर्छ भन्नेमा हुन्छ। OpenVPN मा मध्यस्थ प्रमाणपत्रहरू सर्भर प्रमाणपत्र फाइलसँगै जान सक्छन् वा --extra-certs सँग छुट्टै दिन सकिन्छ, र एउटै विषय नाममुनि लेखिएका दुई मूल भएको बन्डेलले तपाईंको एक क्लाइन्टलाई गलत शाखामा पठाउनेछ।
नाम र उद्देश्य छुट्टाछुट्टै ढोका हुन्
शृंखला निर्माणले कहिल्यै नाम तपाईंको हो कि भनी सोध्दैन। OpenVPN ले यो केवल प्रोफाइलले --verify-x509-name सेट गर्दा जाँच्छ, र केवल सामान्य नाम मिलाउने पुरानो बानी ती प्रमाणपत्रहरूमा टुट्छ जसका पहिचान subjectAltName मा बस्छन्। IKEv2 परिनियोजनहरूले कन्फिगर गरिएको पहिचानलाई SAN प्रविष्टि वा विशिष्ट नामसँग मिलाउँछन्, क्लाइन्टअनुसार, र वाइल्डकार्ड वा %any मानले तपाईंले ठानेको तुलना चुपचाप बन्द गर्छ।
त्यसपछि समय र उद्देश्य आउँछन्। घडी केही घण्टा अगाडि भएको ल्यापटपले अझै वैध नभएको प्रमाणपत्र अस्वीकार गर्छ, र म्याद सकिएको मध्यस्थ प्रमाणपत्रले पात चालु हुँदा पनि मार्ग असफल गर्छ। उद्देश्यका असफलता विस्तारित कुञ्जी प्रयोगमा serverAuth नभएको वा ह्यान्डशेक हस्ताक्षरलाई अनुमति नदिने keyUsage भएको प्रमाणपत्रबाट आउँछ, जसलाई OpenSSL असमर्थित प्रमाणपत्र उद्देश्यका रूपमा जनाउँछ। सही टेम्प्लेटबाट फेरि जारी गर्नुहोस्; त्यो सन्देशमा प्रमाणीकरण बन्द गर्ने कुनै कारण छैन।
रद्दीकरण केवल कसैले त्यो कन्फिगर गरेमा चल्छ
CRL वा OCSP प्रतिक्रिया स्वतः जाँचिँदैन। OpenVPN सर्भरमा क्लाइन्ट प्रमाणपत्रहरू सूचीसँग केवल --crl-verify ले त्यस्तो सूचीतर्फ संकेत गर्दा मात्र तुलना गरिन्छ। सर्भर प्रमाणपत्रको क्लाइन्ट-पक्ष जाँच कार्यान्वयनमा निर्भर छ र प्रायः हुँदैन। strongSwan लाई पीयरका लागि CRL हेर्नु अघि आफ्नो रद्दीकरण प्लगइन र नीति चाहिन्छ।
यसले तपाईंले अन्तमा पाउने टिकट बुझाउँछ: रद्द गरिएको क्लाइन्ट प्रमाणपत्र अझै जोडिन्छ, र सबैले रद्दीकरण बिग्रिएको निष्कर्ष निकाल्छन्। केही पनि जाँचिरहेको थिएन। CRL प्रकाशित गरी ताजा गर्नुहोस्, वा क्लाइन्ट प्रमाणपत्रहरू यति छोटो आयुका राख्नुहोस् कि पुरानो रद्दीकरणले थोरै समय मात्र महत्त्व राखोस्, र घटनाको समयमा आवश्यक पर्नु अघि प्रयोगशाला प्रमाणपत्रमा रद्दीकरण मार्गको अभ्यास गर्नुहोस्।
प्रमाणीकरण चालु राख्ने मर्मत क्रम
फाइलहरू छुनु अघि लक्षणअनुसार क्रम लगाउनुहोस्, किनकि तालिकाको हरेक पङ्क्तिले तपाईंलाई फरक वस्तुतर्फ पठाउँछ।
| Client says | Most likely gate | First check |
|---|---|---|
| unable to get local issuer certificate | trust anchor or missing intermediate | your own openssl verify against the files the profile loads |
| expired or not yet valid | validity window | leaf and intermediate dates against the device clock |
| unsupported certificate purpose | extended key usage | serverAuth present, keyUsage allows the handshake |
| name mismatch | peer identity | subjectAltName entries versus the profile name |
सूची एकै पटकमा सक्नुहोस्: प्रोफाइलले लोड गर्ने फाइल पक्का गर्नुहोस्, मार्ग आफैं बनाउनुहोस्, सर्भरले मध्यस्थ प्रमाणपत्र पठाउँछ कि जाँच्नुहोस्, घडी तुलना गर्नुहोस्, SAN पढ्नुहोस्, EKU पढ्नुहोस्, त्यसपछि फेरि जोडिनुहोस् र त्यही लग लाइन हराउँदै गएको हेर्नुहोस्। यदि यन्त्रलाई CA दिनै सकिँदैन भने, पिनिङ इमानदार विकल्प हो, किनकि OpenVPN 2.6 ले --peer-fingerprint स्वीकार्छ र जाँच हटाउनुको सट्टा भरोसा एउटा कुञ्जीसम्म सीमित गर्छ। यी प्रत्येक क्षेत्रको अर्थका लागि RFC 5280 सन्दर्भ हो।