प्रमाणपत्राचे नाव विसंगत की कालबाह्यता: दोन्ही वेगळे कसे ओळखावे

दोन VPN बिघाड वापरकर्त्याच्या खुर्चीतून सारखेच दिसतात पण उलट्या दुरुस्त्या मागतात. नावाची विसंगती म्हणजे प्रमाणपत्र वैध आहे पण दुसऱ्या कशासाठी जारी केले आहे. कालबाह्यता त्रुटी म्हणजे प्रमाणपत्र या क्षणी वैध नाही. दोन्ही पासवर्डची समस्या नाहीत, आणि दोन्ही बाबतीत क्रेडेन्शियल्स रीसेट करणे हा सर्वात सामान्य वाया गेलेला तास आहे. काहीही हात लावण्यापूर्वी अयशस्वी होणारा टप्पा वाचा.

त्रुटीचा मजकूर हेच निदान आहे

संदेश संक्षिप्त असला तरी कोणती तपासणी अयशस्वी झाली हे क्लायंट सांगतो. विसंगती अपेक्षित होस्टनाव आणि सापडलेले नाव सांगते. कालबाह्यता त्रुटी वैधतेच्या तारखा किंवा वेळेचा उल्लेख करते. ती दोन वाक्ये प्रमाणपत्राच्या वेगवेगळ्या भागांकडे निर्देश करतात.

ती जिथे दिसतात त्या टप्प्यावर वाचा. हँडशेकदरम्यानची अयशस्वीता प्रमाणपत्राची समस्या आहे; बोगदा उभा राहिल्यानंतरची अयशस्वीता मार्गनिर्देशन किंवा क्रेडेन्शियल्सची समस्या आहे. टप्पा टिकवणे हेच तपासणी असंबंधित सेटिंग्जकडे भरकटण्यापासून थांबवते.

अयशस्वीता प्रयत्नांमध्ये बदलत असल्यास तिसरी शक्यता आहे: एकाच नावामागे एकापेक्षा जास्त नोड.

नाव तपासण्या: क्लायंट काय तुलना करतो

क्लायंट अपेक्षित असलेल्या ओळखीची प्रमाणपत्रातील नावांशी तुलना करतो, जी subjectAltName विस्तारात असतात. प्रोफाइलमधील कच्चा IP, प्रमाणपत्र सूचीबद्ध न करणारे उपनाव, किंवा फक्त त्याच सर्व्हरवर निराकरण होणारे नाव — सर्व या तपासणीत अयशस्वी होतात. योग्य मशीनपर्यंत पोहोचणे योग्य ओळख सादर करण्यासारखे नाही.

पूर्वीच्या प्रयत्नातील फाइलऐवजी सर्व्हर प्रत्यक्षात सादर करत असलेले प्रमाणपत्र तपासा. खालील आदेश तुम्ही कॉन्फिगर केलेले नाव मागतो, म्हणून उत्तरात खऱ्या क्लायंटला दिसणारे प्रमाणपत्र समाविष्ट आहे.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

विश्वासार्ह जारीकर्त्याचे प्रमाणपत्र तरीही दुसऱ्या सेवेसाठी असू शकते. क्लायंटच्या नाव तपासण्या सुरू ठेवा, कारण CA वर विश्वास ठेवल्याने त्या CA ने कधीही स्वाक्षरी केलेल्या प्रत्येक नावाला अधिकार मिळत नाही. तपासणी बंद करणे कॉन्फिगरेशन त्रुटीचे उघड होण्यात रूपांतर करते.

कालबाह्यता: कोणाचे घड्याळ वाचले जात आहे

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

काहीही निष्कर्ष काढण्यापूर्वी क्लायंटवर प्रमाणपत्राच्या तारखा UTC शी तुलना करा:

openssl x509 -in cert.pem -noout -dates
date -u

तारखा खरोखर उलटल्या असल्यास जारीकर्त्यामार्फत नूतनीकरण करा. बदली अस्तित्वात असूनही अद्याप वैध झाली नसल्यास, त्यानुसार घड्याळ पुढे करण्याऐवजी समर्थित संक्रमणाचे अनुसरण करा. प्रमाणपत्र समाधानी करण्यासाठी उपकरणाची तारीख मागे नेणे हा बोगद्याच्या खूप पुढील परिणाम असलेला निर्णय आहे.

एक दुरुस्त केल्याने दुसरे का उघडते

पडताळणी तपासण्यांचा क्रम चालवते, आणि पहिली अयशस्वीता अहवाल थांबवते. नाव दुरुस्त करा आणि मग क्लायंट तुम्हाला सांगू शकतो की साखळी अपूर्ण आहे किंवा प्रमाणपत्र कालबाह्य झाले. याचा अर्थ पहिली तपासणी अनावश्यक होती असा नाही. याचा अर्थ साखळीत एकापेक्षा जास्त समस्या होत्या, म्हणून पहिली दुरुस्ती चुकीची होती याचा पुरावा म्हणून न वाचता दुसऱ्या त्रुटीची अपेक्षा करा.

अनेक नोड या गोष्टीला बिघडवतात. लोड-बॅलन्स्ड सेवा वेगवेगळ्या सदस्यांकडून वेगवेगळी प्रमाणपत्रे सादर करू शकते, म्हणून दोनदा उत्तीर्ण होणारी आणि एकदा अयशस्वी होणारी चाचणी तुम्हाला तुमच्या क्लायंटबद्दल नाही तर ताफ्याबद्दल सांगते. निदानात पीअर पत्ता आणि प्रयत्नाची वेळ ठेवा.

तीच तपशील अस्थिर तिकिटाचे पुनरुत्पादनीय तिकिटात रूपांतर करते.

नवीन कनेक्शनने ते सिद्ध करा

दुरुस्तीनंतर जुने पुन्हा सुरू करण्याऐवजी नवीन कनेक्शन उघडा, आणि पूर्वी अयशस्वी होणारा टप्पा आता उत्तीर्ण होतो याची खात्री करा. मग बोगदा खरोखर रहदारी वाहतो याची खात्री करा, कारण यशस्वी हँडशेक हा कार्यरत मार्ग नाही.

अचूक त्रुटी टप्पा आणि प्रमाणपत्राचे तपशील तिकिटासोबत ठेवा.

तीच नोंद पुढच्या व्यक्तीला प्रमाणपत्राच्या समस्येसाठी खाते पासवर्ड रीसेट करण्यापासून रोखते. ओळख आणि वैधता वेगवेगळे प्रश्न आहेत, आणि दुसऱ्याचे मूल्यांकन कसे होते यासाठी RFC 5280 हे संदर्भ आहे.