तुमचा 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 saysMost likely gateFirst check
unable to get local issuer certificatetrust anchor or missing intermediateyour own openssl verify against the files the profile loads
expired or not yet validvalidity windowleaf and intermediate dates against the device clock
unsupported certificate purposeextended key usageserverAuth present, keyUsage allows the handshake
name mismatchpeer identitysubjectAltName entries versus the profile name

यादी एकाच फेरीत पूर्ण करा: प्रोफाइल जी फाइल लोड करते ती खात्री करा, मार्ग स्वतः बांधा, सर्व्हर मध्यस्थ प्रमाणपत्र पाठवतो का ते तपासा, घड्याळाची तुलना करा, SAN वाचा, EKU वाचा, नंतर पुन्हा जोडा आणि तीच लॉग ओळ नाहीशी होताना पहा। उपकरणाला अजिबात CA देता येत नसेल तर पिनिंग हा प्रामाणिक पर्याय आहे, कारण OpenVPN 2.6 --peer-fingerprint स्वीकारते आणि तपासणी काढून टाकण्याऐवजी विश्वास एका कीपर्यंत मर्यादित करते। या प्रत्येक क्षेत्राचा अर्थ काय यासाठी RFC 5280 हा संदर्भ आहे।

संबंधित लेख