प्रमाणपत्रे वैध असतानाही नवीन VPN लॉगिन अयशस्वी होतात: CRL तपासा

अजून काही महिने शिल्लक असलेली प्रमाणपत्रे आणि लगेच अयशस्वी होणारी लॉगिन दोन वेगळ्या घड्याळांवरील दोन वेगळ्या वस्तूंकडे निर्देश करतात। सर्व्हर कनेक्शन नाकारत आहे कारण तो ज्या रद्द केलेल्या प्रमाणपत्रांच्या यादीचा सल्ला घेतो ती स्वतःची कालबाह्यता तारीख ओलांडून गेली आहे, असे नाही की वापरकर्त्यांची प्रमाणपत्रे जुनी झाली आहेत। वापरकर्ता प्रमाणपत्राचे नूतनीकरण केल्याने त्या यादीसाठी काहीच होत नाही.

दोन्ही वेळापत्रके वेगळी करणे हेच संपूर्ण निदान आहे, आणि ते दुरुस्ती कशी असावी हे बदलते.

दोन घड्याळे, आणि त्यातील फक्त एकच प्रमाणपत्र आहे

प्रमाणपत्र वैधतेची एक खिडकी बाळगते। प्रमाणपत्र रद्दीकरण यादी स्वतःची खिडकी बाळगते, शिवाय जारीकर्ता आणि स्वाक्षरी, आणि पडताळणीकर्ते अशा यादीवर विश्वास ठेवण्यास नकार देतात जिची पुढील अद्ययावत वेळ उलटून गेली आहे। असे घडल्यावर क्लायंट पूर्णपणे वैध प्रमाणपत्र सादर करतो आणि सर्व्हर तरीही यादीबद्दलच्या संदेशासह कनेक्शन तोडतो। वापरकर्ते तो संदेश 'प्रमाणपत्र कालबाह्य झाले' असे वाचतात, ज्यामुळे नूतनीकरणाची विनंती चुकीच्या ठिकाणी जाते.

दोन्ही वस्तूंचे मालकही वेगळे आहेत: प्रमाणपत्र ते जारी करणाऱ्या CA कडून येते, तर यादी वेळापत्रकानुसार ती CA चालवणाऱ्या व्यक्तीकडून तयार होते। वापरकर्ता ती ताजी करू शकत नाही, आणि प्रमाणपत्रे पुन्हा जारी केल्याने ती लांबवता येत नाही.

सेवा प्रत्यक्षात जी यादी लोड करते ती वाचा

तुम्ही अपेक्षित असलेल्या फाइलपासून नव्हे, तर चालू असलेल्या कॉन्फिगरेशनपासून सुरुवात करा। crl-verify चा मार्ग निरपेक्ष, प्रोफाइलच्या सापेक्ष, किंवा इमेजमध्ये बसवलेली प्रत असू शकतो, आणि पडताळणीकर्ता तीच प्रत वाचतो। ती तिच्या जागीच openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate ने तपासा आणि तारखा सर्व्हरच्या घड्याळाशी तुलना करा.

मग फाइल खरोखर वापरात असलेलीच आहे याची खात्री करा: openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout ने तिची स्वाक्षरी तपासा, जो क्षेत्रे गुपचूप छापण्याऐवजी पडताळणीचा निकाल कळवतो। दुसऱ्या CA ने स्वाक्षरी केलेली यादी, किंवा दुसऱ्या डिरेक्टरीत राहिलेली जुनी प्रत, कालबाह्य यादीसारखीच अयशस्वी होते.

शून्यातून नव्हे, रद्दीकरण डेटाबेसमधून पुन्हा तयार करा

नवीन यादी CA च्या सध्याच्या रद्दीकरण डेटाबेसमधून, मंजूर स्वाक्षरी प्रक्रियेद्वारे आली पाहिजे। रिकामी यादी तयार करणे, किंवा इंडेक्सच्या जुन्या बॅकअपमधून पुन्हा तयार करणे, त्या बॅकअपनंतर जोडलेल्या प्रत्येक ओळखीचे रद्दीकरण गुपचूप रद्द करते। यामुळे लॉगिन खंड सुरक्षा-घसरणीत बदलतो, आणि लक्षण नाहीसे होत असल्याने कोणाच्याही लक्षात येत नाही.

तयारीची पायरी CA च्या उर्वरित साधनांसोबत आवृत्ती नियंत्रणात ठेवा, जेणेकरून अंतराल आणि स्वाक्षरी की लक्षात ठेवण्याऐवजी दस्तऐवजीकृत होतील। आदेश, स्वाक्षरीकर्ता आणि प्रकाशन लक्ष्य नाव देणारी रनबुक नोंद पुरेशी आहे। मग ड्युटीवरचा कोणीही कोणती इंडेक्स फाइल अधिकृत आहे याचा अंदाज न लावता पुन्हा तयार करू शकतो। यादीचा अनुक्रमांक आणि पुढील अद्ययावत वेळ तैनाती नोंदीसोबत साठवा.

पडताळणीकर्ता जिथे पाहतो तिथेच तैनात करा

नवीन यादी सेवा ज्या मार्गावर वाचते तिथे प्रत करा, मालकी आणि मोड अशा प्रकारे ठेवा की सेवा खात्याला ती वाचता येईल पण इतरांना नाही, आणि दस्तऐवजीकृत वर्तनानुसार पुन्हा लोड किंवा पुन्हा सुरू करा। डीमन सुरुवातीला यादी कॅशे करत असल्यास, पुन्हा लोड न करता फाइल बदलल्याने चालू प्रक्रियेला काहीच जाणवणार नाही। पुन्हा लोड केल्यानंतर प्रक्रिया जो टाइमस्टॅम्प कळवते तो तपासा.

अनेक सेवा क्लायंटची पडताळणी करत असल्यास प्रत्येकीवर तैनात करा। एक एंडपॉइंट अद्ययावत करून दुसरा जुन्या प्रतीसह सोडल्यास अशी अयशस्वीता उद्भवते जी फक्त दुसऱ्यावर पोहोचणाऱ्या वापरकर्त्यांना दिसते। त्या एंडपॉइंटची छोटी यादी त्याच रनबुकमध्ये ठेवा। तैनातीनंतर प्रत पोहोचली असे गृहीत धरण्याऐवजी प्रत्येकीच्या कळवलेल्या यादी-तारखेची तपासणी करा.

पुढील मुदत संपण्यापूर्वी ती दृश्यमान करा

मोठा प्रकाशन-अंतराल प्रक्रिया निर्माण न करता या घटनेची वारंवारता कमी करतो। ऑपरेटरच्या धोरणातून अंतराल निवडा, नंतर पुन्हा तयार करण्यासाठी आणि तैनात करण्यासाठी पुरेसा वेळ ठेवून तैनात यादीच्या पुढील-अद्ययावत क्षेत्रावर इशारा सेट करा। तैनात प्रतीवर इशारा सेट करा, CA होस्टवर नाही, कारण तैनात प्रतच अयशस्वी होते.

तैनातीनंतर दोन्ही दिशा पडताळा: परवानगी असलेला वापरकर्ता जोडतो, आणि ज्ञात रद्द केलेली ओळख तरीही अयशस्वी होते। दुसरी तपासणीच अपूर्ण पुनर्निर्मिती पकडते, आणि त्यासाठी नेमके याच उद्देशासाठी ठेवलेल्या चाचणी प्रोफाइलविरुद्ध एकच आदेश लागतो.