लीफ़ सर्टिफ़िकेट वैध, चेन समाप्त: गहराई पढ़ें

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

गहराई उस सर्टिफ़िकेट का नाम बताती है जो विफल हुआ

OpenSSL निदान में, गहराई 0 लक्ष्य सर्टिफ़िकेट है और गहराई 1 उसे हस्ताक्षरित करने वाला जारीकर्ता है, जबकि बड़ी संख्याएँ ट्रस्ट एंकर की ओर जारी रहती हैं। गहराई 1 पर रिपोर्ट की गई समाप्ति का खंडन लीफ़ पर मौजूद मौजूदा notAfter नहीं करता, इसलिए दृश्य सर्टिफ़िकेट को फिर से जाँचना त्रुटि को कभी नहीं समझाएगा।

विफल सर्टिफ़िकेट की फ़िंगरप्रिंट उसके सब्जेक्ट के साथ दर्ज करें, क्योंकि अलग-अलग सर्टिफ़िकेट एक ही 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 निर्मित चेन प्रिंट करता है, जो यह पुष्टि करने के लिए उपयोगी है कि पथ वही है जो आपने इरादा किया था। जब यह विफल हो, तो रिपोर्ट की गई गहराई और सब्जेक्ट रखें; ये दो फ़ील्ड अगले पाठक को बताते हैं कि कौन-सा सर्टिफ़िकेट निरीक्षण करना है।

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

जाँच क्या सिद्ध करती है और क्या छोड़ देती है

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

सर्वर जो भेजता है वह उम्मीदवारों का समूह है, न कि वह पथ जो आपका क्लाइंट अंततः बनाएगा। स्थानीय ट्रस्ट और लाइब्रेरी के निर्माण नियम दोनों परिणाम को आकार देते हैं, इसीलिए वही उत्तर एक मशीन पर सत्यापित हो सकता है और दूसरी पर विफल। समान मूल्यांकन मानने से पहले विफल क्लाइंट के अनुरक्षित ट्रस्ट स्टोर और TLS कार्यान्वयन की तुलना कार्यशील क्लाइंट से करें। वहाँ का अंतर „केवल यही लैपटॉप विफल होता है“ जैसी कई रिपोर्टों को समझाता है।

प्रत्येक सर्टिफ़िकेट की खिड़की एक-एक करके देखने के बजाय उन्हें समूह के रूप में प्रिंट करें:

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

वह दूसरा कमांड प्रत्येक फ़ाइल को हाथ से डिकोड किए बिना सब्जेक्ट और जारीकर्ताओं को सूचीबद्ध करता है, इसी तरह आप ऐसा मध्यवर्ती सर्टिफ़िकेट पहचानते हैं जिसकी तारीख़ बीत चुकी है जबकि लीफ़ अभी भी ठीक दिखता है।

सत्यापन को कमज़ोर किए बिना पथ ठीक करें

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

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

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