VPN प्रमाणपत्र अझै मान्य छैन: तीन कारण, जाँचको एक क्रम
«अझै मान्य छैन» भन्नाले यन्त्रको घडी पछाडि छ, विन्डो साँच्चै पछि सुरु हुन्छ, वा मध्यस्थ प्रमाणपत्र अझै खुलेको छैन। तिनीहरूलाई यही क्रममा जाँच्नुहोस्।
तपाईं क्लाइन्ट खोल्नुहुन्छ, महिनौंदेखि प्रयोग गर्दै आएको प्रोफाइल छान्नुहुन्छ, र त्यो "certificate is not yet valid" सँग रोकिन्छ। तपाईंको साइन-इनमा केही पनि बदलिएको छैन, र ट्रस्ट स्टोर सायद ठीक छ: ह्यान्डशेकमा प्रस्तुत प्रमाणपत्रमा जाँचकर्ताले प्रयोग गरिरहेको क्षणभन्दा पछि सुरु हुने वैधता विन्डो हुन्छ। तीन फरक परिस्थितिले ठ्याक्कै त्यही सन्देश उत्पन्न गर्छन्, र तिनलाई फरक कदम चाहिन्छ। तलको क्रमले घडी वा प्रमाणपत्र फाइल छुनुअघि तपाईंसँग कुन छ भन्ने बताउँछ।
तीन कारणमध्ये कुन हेर्दै हुनुहुन्छ
पहिलो कारण स्थानीय हो: जाँच गर्ने यन्त्रको घडी प्रमाणपत्रको सुरु मितिभन्दा अगाडिको छ। यो मृत CMOS ब्याट्री भएको हार्डवेयरमा, पुरानो स्न्यापसटबाट पुनर्स्थापित भर्चुअल मेसिनमा, समय गुमाउन पर्याप्त लामो समय बन्द रहेका यन्त्रमा, र बाहिर जाने NTP अवरुद्ध भएको तर कसैले याद नगरेको नेटवर्कमा देखिन्छ। प्रमाणपत्र पूर्ण रूपमा मान्य हुँदाहुँदै पनि यसरी असफल हुन सक्छ।
दोस्रो कारण जारीकर्ताको हो, किनकि प्रमाणपत्र साँच्चै भविष्यमा सुरु हुन्छ: चाँडै जारी गरिएको, स्पष्ट सुरु समयसहित उत्पन्न गरिएको, वा अझै नचलेको सक्रियता चरणको भागका रूपमा हस्ताक्षर गरिएको। तेस्रो कारणले सबैभन्दा बढी समय बर्बाद गर्छ, किनकि पात सक्रिय छ तर प्रस्तुत गरिएको श्रृंखलाको अर्को प्रमाणपत्र छैन, त्यसैले त्रुटिले तपाईंले कहिल्यै स्थापना नगरेको सामग्रीको नाम लिन्छ।
एउटा प्रश्नले तिनलाई छुट्याउँछ। असफलता यन्त्रको पछि लाग्छ कि सेवाको? एउटै नेटवर्कमा फरक व्यवहार गर्ने दुई मेसिनले घडीलाई संकेत गर्छन्। हरेक क्लाइन्ट एउटै तरिकाले असफल भए त्यसले प्रमाणपत्रको विन्डो र त्यसको पछाडिको श्रृंखलालाई संकेत गर्छ।
वास्तवमा प्रस्तुत गरिएको प्रमाणपत्रबाट विन्डो पढ्नुहोस्
अघिल्लो तैनातीबाट बाँकी रहेको PEM फाइल जाँच्नुहोस् न; सेवालाई अहिले पठाइरहेको श्रृंखला सोध्नुहोस्। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts श्रृंखलाको हरेक प्रमाणपत्र छाप्छ। तपाईंलाई चाहिने ब्लक सुरक्षित गर्नुहोस् र openssl x509 -noout -subject -issuer -dates चलाउनुहोस्; अन्तिमले notBefore र notAfter छाप्छ, र ती दुई मानले नै निर्णय गर्छन्। Windows मा, जडानको प्रमाणपत्र संवाद र निर्यात गरिएको फाइलमा certutil -dump ले उही फिल्ड देखाउँछन्।
विन्डोका दुवै छेउ पढ्नुहोस्, सुरु मात्र होइन। दुई घण्टामा खुल्ने प्रमाणपत्र र दुई घण्टामा बन्द हुने प्रमाणपत्र फरक सन्देशसहित असफल हुन्छन् र फरक टोलीलाई संलग्न गराउँछन्। त्रुटिले कुन प्रमाणपत्रको नाम लिन्छ — पात, मध्यस्थ वा मूल — त्यो नोट गर्नुहोस्, किनकि क्लाइन्ट पक्षमा केही सुधार्न सकिन्छ कि सकिँदैन त्यसले निर्धारण गर्छ।
विन्डोको प्रतीक्षा नगरी पनि परीक्षण गर्न सकिन्छ। प्रमाणीकरणले स्पष्ट समय स्वीकार गर्छ: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ले त्यो टाइमस्ट्याम्पमा श्रृंखलाको मूल्याङ्कन गर्छ। असफलता पुनरुत्पादन गर्न हालको समयसहित चलाउनुहोस्, त्यसपछि विन्डो खुलेपछि उही श्रृंखला उत्तीर्ण हुन्छ भनी पुष्टि गर्न प्रमाणपत्रको सुरु समयसहित चलाउनुहोस्। RFC 5280 ले वैधता फिल्ड र त्यसबाहिर प्रमाणपत्र प्रयोग गर्न नहुने नियम परिभाषित गर्छ, र तपाईंको क्लाइन्टले भर्खरै त्यही नियम लागू गरेको छ।
तपाईंको घडी, कि तिनको
यन्त्रको घडीलाई UTC मा प्रमाणपत्रको सुरुसँग, तपाईं विश्वास गर्ने स्रोतबाट तुलना गर्नुहोस्। date -u ले क्षण दिन्छ, र systemd होस्टमा timedatectl status ले घडी सिङ्क्रोनाइज भएको छ कि छैन पनि जानकारी दिन्छ। Windows मा, w32tm /query /status ले हालको स्रोत र अन्तिम सफल सिङ्क देखाउँछ। ट्रेमा देखिने टाइमजोन प्रदर्शनको छनोट हो, गलत घडी होइन; जाँचकर्ताले UTC क्षणहरू तुलना गर्छ।
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
घडी पछाडि छ भने, कुनै पनि प्रमाणपत्र सामग्री बदल्नुअघि पुनः सिङ्क गर्नुहोस् र फेरि परीक्षण गर्नुहोस्। केही मिनेट वा घण्टा गलत यन्त्रले सामु पर्ने हरेक भर्खरै जारी प्रमाणपत्र अस्वीकार गर्छ, एउटा सेवा मात्र होइन, त्यसैले एक-सेवा व्याख्या सामान्यतया गलत हुन्छ। घडी सही र सिङ्क्रोनाइज छ भने यन्त्रतिर हेर्न बन्द गर्नुहोस्: विन्डो जारीकर्ताको हो, र त्यो उत्तीर्ण होस् भनेर कुनै स्थानीय सेटिङ बदल्नु हुँदैन।
त्यो तालिका नै पूरा निर्णय हो। घडीलाई प्रमाणपत्रले अपेक्षा गरेको मानमा सार्नु मर्मत होइन, र समय-जाँच बन्द गर्नु पनि मर्मत होइन, किनकि दुवैले त्रुटि उत्पन्न गर्ने अवस्था लुकाउँछन्।
पात ठीक देखिँदा पनि श्रृंखला किन असफल हुन्छ
नवीकरण गरिएका पात र प्रतिस्थापन मध्यस्थ प्रमाणपत्र सामान्यतया सँगै पठाइन्छ, र सधैं एउटै क्षणमा पुग्दैनन्। सेवाले आफ्नै विन्डो पछि सुरु हुने मध्यस्थबाट हस्ताक्षरित नयाँ पात पठाउन सक्छ, वा नयाँ पातमुनि पुरानो मध्यस्थ दिइरहन सक्छ। दुवै हालतमा पातका आफ्नै मितिहरू उचित देखिँदा पनि श्रृंखला असफल हुन्छ।
लोड-सन्तुलित अन्त्यबिन्दुले यसलाई भाँचिएकोबाट असंगतमा बदल्छ। पुनः प्रयास सफल भयो, वा एउटा नेटवर्क चल्यो र अर्को चलेन भने, सेटिङ बदल्नुअघि कुन पियरले जवाफ दियो र कुन श्रृंखला पठायो नोट गर्नुहोस्। openssl s_client ले जोडिएको ठेगाना छाप्छ, त्यसैले केही प्रयासले हरेक नोडले उही श्रृंखला दिन्छ कि दिँदैन खुलाउँछ।
प्रमाणीकरण अक्षुण्ण राख्ने मर्मत मार्ग
घडीको समस्या यन्त्रमै प्रमाणीकरण खुला राखेर सुधारिन्छ। प्रमाणपत्रको समस्या अपरेटरले अहिले समावेश भएको विन्डोका लागि जारी गरिएको सामग्रीले सुधार्छ। कुनै क्लाइन्ट सेटिङले अझै-अवैध प्रमाणपत्रलाई वैध बनाउँदैन; समय-जाँच छोड्ने फ्ल्यागहरू निदान पुष्टि गर्नका लागि हुन्, उत्पादनमा पठाउनका लागि होइन।
प्रमाणपत्र योजनाबद्ध सक्रियताका लागि तयार गरिएको छ भने कटओभर योजना पालना गर्नुहोस्। यसको विन्डो खुल्दा स्थापना गर्नुहोस्, वा आपूर्तिकर्ताले अभिलेख गरेको ओभरल्याप प्रक्रिया प्रयोग गर्नुहोस्, चाँडै स्थापना गरेर प्रयोगकर्तालाई चेतावनीमार्फत क्लिक गर्न सिकाउनुको सट्टा। मानिसहरूले बेवास्ता गर्न सिकेका चेतावनीहरू छोटो ढिलाइभन्दा महँगो पर्छन्।
अन्तमा, असफलता जसरी भयो त्यसरी नै फेरि परीक्षण गर्नुहोस्: नयाँ सत्र, उही क्लाइन्ट, तपाईंलाई साँच्चै चाहिने स्रोत। TLS पुस्तकालयहरूले जडानको जीवनभर प्रमाणित श्रृंखला क्यास गर्न सक्छन्, र पुनः सुरु गरिएको सत्रले त्यसलाई फेरि जाँच्छ भन्ने छैन, त्यसैले पुरानो सत्र मर्मतपछि पनि असफल हुँदै जान सक्छ वा रिग्रेसनपछि पनि काम गर्दै जान सक्छ। भ्युअरमा खुल्ने फाइलले फाइल पढ्न योग्य छ भन्ने मात्र प्रमाणित गर्छ; पूरा भएको ह्यान्डशेकले श्रृंखला प्रमाणित हुन्छ भन्ने प्रमाणित गर्छ।
टिकट बन्द गर्नुअघि चार कुरा पुष्टि गर्नुहोस्: असफल यन्त्रको UTC समय र सिङ्क स्थिति, प्रस्तुत श्रृंखलाको हरेक प्रमाणपत्रको notBefore र notAfter, दोस्रो क्लाइन्टबाट उही श्रृंखला, र त्रुटिले प्रमाणपत्रलाई दिने नाम। घडी सही छ र विन्डो खुलेको छैन भने बाँकी अपरेटरको काम हो, र तपाईंको पक्षबाट सही कदम प्रमाणीकरण कमजोर पार्नु होइन, विन्डो पर्खनु हो।