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

सर्भर प्रमाणपत्रको उद्देश्य सही देखिन्छ, कुञ्जी मिल्छ, मितिहरू ठीक छन्, र जडान अझै 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 लाई अर्थ दिने सीमा हटाउँछ, र सामान्यतया यसलाई निम्त्याएको घटनाभन्दा लामो समय टिक्छ। प्रोफाइलमा अधिकारले कुन भूमिका प्रमाणित गर्न सक्छ भनी बताउने सानो टिप्पणीले अर्को पुनर्जारीलाई त्यही बहस दोहोर्‍याउनबाट रोक्छ।

प्रमाणीकरण बन्द गर्नु अर्को लोभ्याउने छोटो बाटो हो, र यसले प्रमाणपत्रको समस्यालाई विश्वासको समस्यामा बदल्छ। उद्देश्य जाँच यथावत् राख्नुहोस्, चेन सुधार्नुहोस् र मार्गले अब इच्छित भूमिका पूरा गर्छ भनी पुष्टि गर्न त्यही अफलाइन प्रमाणीकरण फेरि चलाउनुहोस्, त्यसपछि सेवालाई फेरि छुनुहोस्।