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, दुसऱ्या क्लायंटकडून तीच साखळी, आणि त्रुटी प्रमाणपत्राला देत असलेले नाव। घड्याळ बरोबर असेल आणि विंडो उघडली नसेल, तर उर्वरित ऑपरेटरचे काम आहे, आणि तुमच्या बाजूने योग्य पाऊल पडताळणी कमकुवत करण्याऐवजी विंडोची वाट पाहणे आहे।