लीफ प्रमाणपत्र मान्य, चेन सकियो: गहिराइ पढ्नुहोस्

तपाईं सर्भर प्रमाणपत्र जाँच्नुहुन्छ, घडीमा अझै महिना बाँकी देख्नुहुन्छ, र क्लाइन्टले अझै समाप्ति सन्देशसहित जडान अस्वीकार गर्छ। तपाईंले पढ्नुभएको मिति लीफको हो, र गुनासो मार्गको अझ गहिरो कुनै कुराबारे हुन सक्छ। प्रमाणीकरण एउटा चेनबाट जान्छ, र यो यात्राले छान्ने कुनै पनि प्रमाणपत्र आफ्नै वैधता विन्डोमा असफल हुन सक्छ। केही नवीकरण गर्नुअघि कुन असफल भयो पढ्नुहोस्।

गहिराइले असफल भएको प्रमाणपत्रको नाम दिन्छ

OpenSSL निदानमा, गहिराइ 0 लक्ष्य प्रमाणपत्र हो र गहिराइ 1 त्यसमा हस्ताक्षर गर्ने जारीकर्ता हो, ठूला संख्याहरू ट्रस्ट एङ्करतिर जारी रहन्छन्। गहिराइ 1 मा रिपोर्ट गरिएको समाप्ति लीफमा रहेको वर्तमान notAfter ले खण्डन गर्दैन, त्यसैले देखिने प्रमाणपत्र फेरि जाँच्दा त्रुटि कहिल्यै व्याख्या हुनेछैन।

असफल प्रमाणपत्रको फिङ्गरप्रिन्ट यसको subject सँगै लेख्नुहोस्, किनकि फरक प्रमाणपत्रले एउटै CA नाम बोक्न सक्छन्। क्रस-साइनिङले ठ्याक्कै त्यही अवस्था सिर्जना गर्छ: उही अधिकार एकभन्दा बढी पटक, फरक वैधता मितिहरूसहित देखा पर्छ, र प्रमाणीकरणकर्ताले तपाईंले अपेक्षा नगरेको छान्यो। परिचित लेबल पहिचानकर्ता होइन, र फिङ्गरप्रिन्टले एउटै नाम साझा गर्ने दुई वस्तुलाई छुट्याउँछ।

एकभन्दा बढी प्रमाणपत्र भूमिका भएका उत्पादनहरूमा पनि ध्यान दिनुहोस्। OpenVPN Access Server मा, वेब इन्टरफेसको सुरक्षा गर्ने प्रमाणपत्रहरू VPN जडानका लागि प्रयोग हुनेहरूबाट अलग छन्, त्यसैले एडमिन पृष्ठ खोल्ने ब्राउजरले टनेलको मार्गबारे केही पनि प्रमाणित गर्दैन।

ट्रस्ट इनपुट र चेन उम्मेदवार एउटै होइनन्

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

पूर्वनिर्धारित मार्ग र भण्डारलाई -no-CApath -no-CAstore सँग असक्षम गर्नुले परीक्षण इमानदार राख्छ: नतिजा तपाईंले नाम दिएका फाइलहरूमा निर्भर हुन्छ, वर्कस्टेशनले संयोगवश विश्वास गर्ने कुरामा होइन। OpenSSL प्रमाणीकरण सन्दर्भ यी विकल्पहरू र तिनले उत्पादन गर्ने निदानको दस्तावेजीकरण गर्छ।

प्रमाणीकरण सफल हुँदा -show_chain बनाइएको चेन प्रिन्ट गर्छ, जुन मार्ग तपाईंले चाहेको हो भनी पुष्टि गर्न उपयोगी हुन्छ। असफल हुँदा, रिपोर्ट गरिएको गहिराइ र subject राख्नुहोस्; ती दुई फिल्डले अर्को पाठकलाई कुन प्रमाणपत्र जाँच्ने भनी बताउँछन्।

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

जाँचले के प्रमाणित गर्छ र के छोड्छ

यो तपाईंले दिनुभएको ट्रस्ट फाइलविरुद्ध मार्ग र उद्देश्यको जाँच हो। HTTPS नाम जाँचका लागि उपयुक्त विकल्पमार्फत अपेक्षित होस्टनाम थप्नुहोस्; VPN जडानका लागि क्लाइन्टका कन्फिगर गरिएका पहिचान जाँच राख्नुहोस् र त्यो क्लाइन्टले साँच्चै पढ्ने ट्रस्ट सामग्री प्रयोग गर्नुहोस्।

सर्भरले पठाउने कुरा उम्मेदवारहरूको समूह हो, तपाईंको क्लाइन्टले अन्तमा बनाउने मार्ग होइन। स्थानीय ट्रस्ट र पुस्तकालयको निर्माण नियम दुवैले नतिजा आकार दिन्छन्, त्यसैले एउटै प्रतिक्रिया एक मेसिनमा प्रमाणित हुन सक्छ र अर्कोमा असफल हुन सक्छ। समान मूल्याङ्कन मान्नुअघि असफल क्लाइन्टको व्यवस्थित ट्रस्ट भण्डार र TLS कार्यान्वयनलाई कार्यरत क्लाइन्टसँग तुलना गर्नुहोस्। त्यहाँको फरकले „यो ल्यापटपमा मात्र असफल हुन्छ“ भन्ने धेरै रिपोर्ट व्याख्या गर्छ।

प्रत्येक प्रमाणपत्रको विन्डो एक-एक गरी नहेरी समूहका रूपमा हेर्न, तिनलाई यसरी प्रिन्ट गर्नुहोस्:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

त्यो दोस्रो आदेशले प्रत्येक फाइल हातले डिकोड नगरी subject र जारीकर्ताहरूको सूची बनाउँछ, यसरी लीफ अझै ठीक देखिँदा मिति नाघेको मध्यस्थ प्रमाणपत्र भेट्नुहुन्छ।

प्रमाणीकरण कमजोर नबनाई मार्ग मर्मत गर्नुहोस्

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

जरा ह्यान्डलिङ एउटा टिप्पणीको योग्य छ, किनकि सारांशहरूले यसलाई प्रायः बढाइचढाइ गर्छन्। RFC 5280 एङ्करलाई भावी मार्ग बाहिर रहेको इनपुट मान्छ, जबकि OpenSSL आफ्नो जरा CA प्रमाणपत्र समावेश गर्ने वैधता जाँचहरूको दस्तावेजीकरण गर्छ। दुवै भनाइ तिनका आफ्नै प्रणालीका लागि सत्य हुन्; एउटा पुस्तकालयको जरा-समाप्ति व्यवहार सबै क्लाइन्टमा सामान्यीकरण गर्दा आत्मविश्वासी गलत उत्तरहरू दिन्छ।

परिवर्तनपछि, प्रभावित क्लाइन्टमा नयाँ प्रमाणीकरण बाध्य गर्नुहोस् र विशिष्ट समाप्ति सन्देश गएको पुष्टि गर्नुहोस्। लीफ आफैं अनुपयुक्त भएमा मात्र लीफ नवीकरण गर्नुहोस्। समय जाँच असक्षम गर्ने वा ऐतिहासिक क्रस-प्रमाणपत्र पुनर्स्थापित गर्ने कार्यले वैध वर्तमान मार्ग बनाउँदैन; यसले अर्को असफलता मात्र ढिलो बनाउँछ।