प्रमाणपत्रको नाम अमेल वा म्याद सकिने: दुवैलाई कसरी छुट्याउने

दुई 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 सन्दर्भ हो।