असमर्थित प्रमाणपत्र उद्देश्य: मध्यस्थ CA का अपयशी होतो
जेव्हा OpenVPN असमर्थित प्रमाणपत्र उद्देश्याची नोंद करते, तेव्हा लीफ प्रमाणपत्र निर्दोष असू शकते। काहीही पुन्हा जारी करण्यापूर्वी लीफच्या उद्देश्याची साखळीच्या धोरणाशी तुलना करा।
सर्व्हर प्रमाणपत्राचा उद्देश्य योग्य दिसतो, की जुळते, तारखा ठीक आहेत, आणि तरीही कनेक्शन unsupported certificate purpose सह अपयशी होते। हे सोडवणारा तपशील सहसा त्रुटीच्याच ओळीत असतो: साखळीत वरच्या प्रमाणपत्राचे नाव देणारे खोली मूल्य आणि subject। दोन वेगवेगळ्या चाचण्या चालू आहेत, आणि त्यातील फक्त एक लीफशी संबंधित आहे। त्यांची तुलना केल्यास सर्व्हर प्रमाणपत्र बदलल्याने काहीही का बदलत नाही हे स्पष्ट होते।
पडताळणीकर्त्याने प्रत्यक्षात कोणते प्रमाणपत्र नाकारले
साखळी म्हणजे तीन वेळा पुनरावृत्त एक वस्तू नाही। लीफ सर्व्हरचे नाव आणि की वाहते, मध्यस्थ प्रमाणपत्रे तिला मूळाशी जोडतात, आणि प्रत्येकाचा स्वतःचा वैधता कालावधी, मर्यादा आणि उपयोग असतो। त्रुटी खोली सांगते तेव्हा ती संख्या पडताळणीकर्त्याने बांधलेल्या साखळीतील स्थान दर्शवते, आणि सर्व्हर अनपेक्षित साखळी पाठवत असेल तर ते तुम्ही अपेक्षित स्थान नसू शकते।
त्या खोलीतील प्रमाणपत्राची क्षेत्रे वाचा, दोषी मानलेल्या प्रमाणपत्राची नाही। प्रत्येक क्षेत्र ओतण्याऐवजी जारी करण्यास मर्यादित करणारे दोन extensions मागा, कारण उत्तर जवळजवळ नेहमी त्यापैकी एकात असते। extensions चे आउटपुट सामायिक करणे सुरक्षित आहे; खाजगी की कधीही नाही।
openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage
जर नामनिर्देशित प्रमाणपत्र मध्यस्थ असेल आणि त्याचा विस्तारित की वापर TLS सर्व्हर प्रमाणीकरणाशी असंबंधित गोष्टीचा उल्लेख करत असेल, तर उर्वरित अपयश यांत्रिकपणे येते। OpenVPN ने मागितलेल्या उद्देश्यासाठी साखळी वापरता येत नाही।
लीफचा उद्देश्य आणि साखळीचे धोरण या दोन चाचण्या आहेत
लीफ चाचणी एक संकुचित प्रश्न विचारते: हे अंतिम घटक प्रमाणपत्र या नावासाठी सर्व्हर प्रमाणीकरणास परवानगी देते का? साखळीची चाचणी अधिक व्यापक प्रश्न विचारते: मार्गातील प्रत्येक प्रमाणपत्र त्या उद्देश्यासाठी सेवा देऊ शकते का? फक्त क्लायंट प्रमाणपत्रे जारी करण्यास परवानगी असलेली प्रमाणपत्र प्राधिकरण स्वतःच्या स्वाक्षरी तपासण्या पास करेल आणि तरीही दुसऱ्या चाचणीत अपयशी होईल, कारण ती ज्या मार्गास अधिकृत करते त्यात अॅप्लिकेशनला आवश्यक असलेल्या उद्देश्याचा समावेश नाही। दोन्ही चाचण्या एकाच शब्दांनी अपयशी होतात आणि त्यांच्या दुरुस्त्या पूर्णपणे वेगळ्या आहेत।
म्हणूनच सर्व दृश्यमान क्षेत्रांत योग्य असलेले नव्याने जारी केलेले लीफ त्वरित अपयशी होऊ शकते। म्हणूनच दुरुस्ती सहसा VPN संरचनेत नसून जारी करणाऱ्या प्राधिकरणाच्या प्रोफाइलमध्ये असते।
अनुपस्थित EKU हे निर्बंधक EKU नाही
RFC 5280 विस्तारित की वापराचे extension ऐच्छिक करते आणि ते अस्तित्वात असल्यास निर्बंधक असते। त्यामुळे extension नसलेले CA प्रमाणपत्र सर्व्हर प्रमाणीकरणास 'नाही' म्हणाले नाही, तर केवळ असंबंधित उद्देश्य सूचीबद्ध करणाऱ्याने अगदी विशिष्ट गोष्ट सांगितली आहे। या दोन स्थितींना समतुल्य मानल्यास चुकीचे निदान आणि त्याहून वाईट म्हणजे चुकीची दुरुस्ती मिळते। हा फरक कन्सोलमध्ये सारखी दिसणारी दोन प्राधिकरणे साखळीत पूर्णपणे वेगळी का वागतात हे देखील स्पष्ट करतो।
लायब्ररींचे वर्तनही येथे एकसमान नाही। OpenSSL चे पडताळणी पर्यायांवरील दस्तऐवज CA प्रमाणपत्रांवरील उद्देश्य तपासण्यांबाबतचा स्वतःचा दृष्टिकोन वर्णन करते, आणि तो दृष्टिकोन अंमलबजावणी धोरण आहे, प्रत्येक TLS स्टॅक एकसारखे पाळत असलेला नियम नाही। तुमचे पडताळणीकर्ते काय करते ते वर्णन करा, नंतर तुम्ही प्रत्यक्षात चालवत असलेल्या आवृत्तीवर ते पुष्ट करा।
पुन्हा जारी करण्यापूर्वी अपयश ऑफलाइन पुनरुत्पादित करा
ऑफलाइन पडताळणी अॅप्लिकेशनला समीकरणातून बाहेर काढते। जर साखळी त्याच उद्देश्याखाली त्याच प्रकारे अपयशी होत असेल, तर प्रमाणपत्र हीच समस्या आहे आणि कोणतेही सर्व्हर संरचना ती लपवू शकत नाही। जर साखळी ऑफलाइन पास होत असेल आणि सेवा अजूनही नकार देत असेल, तर अॅप्लिकेशन वेगळे उद्देश्य मागत आहे किंवा तुम्ही तपासलेल्यापेक्षा वेगळी साखळी वापरत आहे।
openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem
-show_chain महत्त्वाचे आहे कारण ते साधनाने बांधलेला मार्ग छापते, आणि तो बहुतेक वेळा तुम्ही दिलेला फाइल क्रम नसतो। ते आउटपुट दुसरे मध्यस्थ प्रमाणपत्र ट्रस्ट स्टोअरमधून ओढले जात असल्याचे, सर्व्हर तुमच्या हेतूशिवाय क्रॉस-साइन्ड प्रकार पाठवत असल्याचे, किंवा ट्युटोरियलमधून कॉपी केलेला उद्देश्य ध्वज सेवा दिल्या जात असलेल्या भूमिकेपेक्षा वेगळ्या भूमिकेचा असल्याचे शोधण्याचा सर्वात जलद मार्ग आहे।
जारी करण्याचे धोरण दुरुस्त करा, पडताळणी कॉल नाही
टिकाऊ दुरुस्ती म्हणजे सेवा द्यावयाच्या उद्देश्यांना परवानगी देणाऱ्या धोरणाखाली जारी केलेले मध्यस्थ प्रमाणपत्र, आणि मर्यादा लिहून पुनरावलोकित केलेली असते। प्रत्येक प्राधिकरणात प्रत्येक उद्देश्य जोडणे हे धोरण नाही; ते extension ला अर्थ देणारी मर्यादा काढून टाकते, आणि सहसा ती घडवून आणलेल्या घटनेपेक्षा जास्त काळ टिकते। प्रोफाइलमध्ये प्राधिकरण कोणत्या भूमिका प्रमाणित करू शकते हे सांगणारी छोटी नोंद पुढील पुनर्जारीला तोच वाद पुन्हा करण्यापासून रोखते।
पडताळणी बंद करणे हा दुसरा मोहक शॉर्टकट आहे, आणि तो प्रमाणपत्राची समस्या विश्वासाच्या समस्येत बदलतो। उद्देश्य तपासणी जागच्या जागी ठेवा, साखळी दुरुस्त करा आणि मार्ग आता इच्छित भूमिकेची सेवा देतो याची पुष्टी करण्यासाठी तीच ऑफलाइन पडताळणी पुन्हा चालवा, त्यानंतर सेवेला पुन्हा स्पर्श करा।