प्रमाणपत्र का नाम असंगत या समाप्ति: दोनों में अंतर कैसे करें

दो 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 संदर्भ है।