आपका 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 है।