लीफ प्रमाणपत्र वैध, साखळी संपली: खोली वाचा

तुम्ही सर्व्हर प्रमाणपत्र तपासता, घड्याळावर अजून महिने शिल्लक दिसतात, आणि क्लायंट तरीही समाप्ती संदेशासह कनेक्शन नाकारतो। तुम्ही वाचलेली तारीख लीफची आहे, आणि तक्रार मार्गातील अधिक खोलवरच्या कशाबद्दल असू शकते। पडताळणी साखळीतून जाते, आणि या फेरीत निवडलेले कोणतेही प्रमाणपत्र स्वतःच्या वैधता-विंडोमध्ये अपयशी ठरू शकते। काहीही नूतनीकरण करण्यापूर्वी कोणते अपयशी ठरले ते वाचा।

खोली अपयशी ठरलेल्या प्रमाणपत्राचे नाव सांगते

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 प्रमाणपत्राचा समावेश असलेल्या वैधता तपासण्यांची नोंद ठेवतो। दोन्ही विधाने त्यांच्या स्वतःच्या प्रणालींसाठी खरी आहेत; एका लायब्ररीचे रूट-समाप्ती वर्तन प्रत्येक क्लायंटवर सामान्यीकृत केल्यास आत्मविश्वासाने चुकीची उत्तरे मिळतात।

बदलानंतर, प्रभावित क्लायंटवर नवीन प्रमाणीकरण सक्तीने करा आणि विशिष्ट समाप्ती संदेश गेला आहे याची खात्री करा। लीफ स्वतःच अयोग्य असेल तरच लीफचे नूतनीकरण करा। वेळ तपासण्या अक्षम करणे किंवा ऐतिहासिक क्रॉस-प्रमाणपत्र पुनर्संचयित करणे वैध सध्याचा मार्ग तयार करत नाही; ते पुढील अपयश फक्त लांबवते।