असमर्थित प्रमाणपत्र उद्देश्य: मध्यवर्ती CA क्यों विफल होता है

सर्वर प्रमाणपत्र का उद्देश्य सही दिखता है, कुंजी मेल खाती है, तिथियाँ ठीक हैं, और कनेक्शन फिर भी unsupported certificate purpose के साथ विफल हो जाता है। इसे हल करने वाला विवरण आमतौर पर त्रुटि की उसी पंक्ति में होता है: एक गहराई मान और एक subject जो श्रृंखला में ऊपर के प्रमाणपत्र का नाम लेते हैं। दो अलग परीक्षण चल रहे हैं, और उनमें से केवल एक लीफ़ के बारे में है। उनकी तुलना समझाती है कि सर्वर प्रमाणपत्र बदलने से कुछ क्यों नहीं बदलता।

सत्यापनकर्ता ने वास्तव में कौन-सा प्रमाणपत्र अस्वीकार किया

श्रृंखला तीन बार दोहराई गई एक वस्तु नहीं है। लीफ़ सर्वर का नाम और कुंजी रखता है, मध्यवर्ती प्रमाणपत्र उसे एक रूट से जोड़ते हैं, और प्रत्येक की अपनी वैधता अवधि, बाधाएँ और उपयोग हैं। जब त्रुटि कोई गहराई बताती है, तो वह संख्या सत्यापनकर्ता द्वारा बनाई गई श्रृंखला में एक स्थिति की पहचान करती है, और यदि सर्वर अप्रत्याशित श्रृंखला भेजता है तो यह वह स्थिति नहीं हो सकती जिसकी आप अपेक्षा करते हैं।

उस गहराई के प्रमाणपत्र के फ़ील्ड पढ़ें, न कि उस प्रमाणपत्र के जिसे आपने दोषी माना था। हर फ़ील्ड डंप करने के बजाय वे दो extensions माँगें जो जारी करने को सीमित करते हैं, क्योंकि उत्तर लगभग हमेशा उनमें से एक में होता है। extension का आउटपुट साझा करना सुरक्षित है; निजी कुंजियाँ कभी नहीं।

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 को अर्थ दिया था, और आमतौर पर यह उस घटना से अधिक जीता है जिसने इसे जन्म दिया। प्रोफ़ाइल में एक छोटी टिप्पणी जो बताती है कि प्राधिकरण किन भूमिकाओं को प्रमाणित कर सकता है, अगली बार फिर से जारी करने को वही बहस दोहराने से रोकती है।

सत्यापन बंद करना दूसरा लुभावना शॉर्टकट है, और यह प्रमाणपत्र की समस्या को विश्वास की समस्या में बदल देता है। उद्देश्य जाँच को यथावत रखें, श्रृंखला सुधारें और वही ऑफ़लाइन सत्यापन फिर चलाएँ ताकि पुष्टि हो कि पथ अब इच्छित भूमिका की सेवा करता है, इससे पहले कि आप सेवा को फिर छुएँ।