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, दूसरे क्लाइंट से वही श्रृंखला, और वह नाम जो त्रुटि प्रमाणपत्र को देती है। अगर घड़ी सही है और विंडो नहीं खुली, तो बाकी ऑपरेटर का काम है, और आपकी ओर से सही कदम सत्यापन कमज़ोर करने के बजाय विंडो का इंतज़ार करना है।