ca md too weak: प्रमाणपत्र पुन्हा जारी करायचे की स्तर खाली आणायचा?

OpenVPN क्लायंट गेल्या महिन्यात चालत होता, आता सुरुवातीला या त्रुटीने अयशस्वी होतो: ca md too weak, आणि डिस्कवरील प्रोफाइल चालणाऱ्या आवृत्तीशी बाइट-बाइट सारखेच आहे. संदेश प्रमाणपत्र प्राधिकरणाच्या प्रमाणपत्रावरील स्वाक्षरीबद्दल आहे, डेटा सिफर, auth डायजेस्ट किंवा खाते पासवर्डबद्दल नाही. तीन अटी ठरवतात की उपाय नवीन ओळख सामग्री आहे, नवीन साखळी आहे, की जाणीवपूर्वक धोरण बदल आहे. त्या क्रमाने करा, म्हणजे होस्टवरील प्रत्येक TLS कनेक्शन कमकुवत करून बोगदा परत आणण्याचा नेहमीचा परिणाम टाळाल.

त्रुटी प्रत्यक्षात काय सांगते

OpenSSL ही पडताळणी त्रुटी साखळी तयार करताना उठवते, जेव्हा CA म्हणून काम करणाऱ्या प्रमाणपत्रावर अशी स्वाक्षरी डायजेस्ट असते जी लायब्ररीची सुरक्षा पातळी आता स्वीकारत नाही. MD5 डीफॉल्ट पातळीवर नाकारली जाते, आणि SHA-1 पातळी वाढवताच नाकारली जाते. इथे पान प्रमाणपत्रावरील डायजेस्टपेक्षा त्यावर स्वाक्षरी करणाऱ्या जारीकर्त्याचा डायजेस्ट अधिक महत्त्वाचा आहे. तेच धोरण जारी केल्याच्या दिवशी पूर्णपणे सामान्य असलेले मूळही नाकारू शकते.

म्हणूनच auth किंवा data-ciphers संपादित करण्याने या अपयशासाठी काहीही होत नाही. त्या सेटिंग्ज हँडशेकनंतर पॅकेट कसे संरक्षित होतात ते ठरवतात, तर नाकारलेली वस्तू बोगदा अस्तित्वात येण्यापूर्वी तपासली जाणारी ओळखपत्र आहे. प्रमाणपत्र त्याच्या वैधता कालावधीत आरामात बसू शकते आणि तरीही लायब्ररी स्वीकारणार नाही अशी स्वाक्षरी बाळगू शकते.

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

पहिली अट: नाकारलेली वस्तू मूळ आहे का?

प्रोफाइलमधील प्रत्येक प्रमाणपत्र छापा आणि subject व issuer क्षेत्रे वाचा. स्वतःवर स्वाक्षरी केलेले मूळ दोन्हीत समान मूल्य दाखवते, आणि त्याचा स्वाक्षरी अल्गोरिदम हाच संपूर्ण साखळीचा आधार आहे. कमकुवत डायजेस्ट तिथे असेल, तर त्याखालील प्रत्येक पान समस्या वारसाहक्काने घेते. पुढील तुलना स्मरणातून नाही तर यांत्रिक व्हावी म्हणून अल्गोरिदम subjectच्या शेजारी लिहा.

एकत्रित CA फाइलींमध्ये अनेक ब्लॉक्स असतात, म्हणून पहिलाच दोषी असे गृहीत धरण्याऐवजी प्रत्यक्षात लोड होणारा ब्लॉक ओळखा. कमांड openssl x509 -in ca.pem -noout -subject -issuer -text एका वेळी एकच प्रमाणपत्र वर्णन करते, म्हणजे बंडलमध्ये अधिक असल्यास आधी तो विभागावा लागतो. छापलेल्या स्वाक्षरी अल्गोरिदमची तुलना मूळ तयार झाल्या काळातून अपेक्षित असलेल्या डायजेस्टशी करा.

कमकुवत मूळाखाली SHA-256 ने स्वाक्षरी केलेले पानही अयशस्वी होते, कारण साखळी तपासणी अगदी वरपर्यंत जाते. हाच क्रम पुढील अट महत्त्वाची करतो.

दुसरी अट: जारीकर्ता तुमच्या नियंत्रणात आहे का?

मूळ तुमच्या संस्थेचे असेल, तर टिकाऊ उपाय म्हणजे आधुनिक डायजेस्टसह नवे मूळ आणि पुन्हा जारी केलेली पाने, एकाच प्रोफाइल अद्ययावत स्वरूपात दिलेली. त्यासाठी देखभाल विंडो आणि त्याच दिवशी अद्ययावत घेऊ न शकणाऱ्या उपकरणांसाठी योजना लागते.

साखळी तिसऱ्या पक्षाने जारी केली असेल, तर उपाय म्हणजे त्या ऑपरेटरकडे विनंती, आणि स्थानिक पातळीवर एकमेव उपयुक्त कृती म्हणजे जुन्या सामग्रीवर अवलंबून राहणे थांबवणे. PEM मजकूर संपादित करणे किंवा फाइल पुन्हा जतन करणे यामुळे स्वाक्षरी जे व्यापते त्यात काहीही बदलत नाही.

एक मधली परिस्थिती नाव देण्यासारखी आहे: सध्याच्या डीफॉल्टपेक्षा जुने अंतर्गत मूळ, पण तरीही इतर प्रणाली विश्वास ठेवतात अशा सामग्रीवर स्वाक्षरी करणारे. ते बदलणे म्हणजे प्रत्येक ग्राहकाचे ऑडिट, जुन्या प्रमाणपत्राला बोटांच्या ठशाने पिन करणाऱ्या उपकरणांसह. बदल नियोजित करण्यापूर्वी ते ग्राहक मोजा, कारण एकाही ग्राहकाला सोडणारा मूळ बदल सुरुवातीची त्रुटी थांब्यात बदलतो.

तिसरी अट: पातळी खाली आणल्याने आणखी काय स्वीकारले जाते

सुरक्षा पातळी खाली आणणे किंवा OpenVPNचे जुने प्रमाणपत्र प्रोफाइल निवडणे यामुळे क्लायंट पुन्हा जुना डायजेस्ट स्वीकारतो. त्याच लायब्ररीतील इतर तपासण्याही ती प्रक्रिया जे जे कनेक्शन करते त्यासाठी सैल होतात.

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

अपवाद जबाबदार व्यक्ती आणि काढण्याच्या पायरीसह लिहून ठेवा. सहा महिन्यांनंतर नोंद न केलेला पातळी बदल चुकीपासून वेगळा ओळखता येत नाही, आणि पुढच्या अभियंत्याला तो कधी निर्णय होता हे कळणार नाही.

निर्णय, नियम म्हणून लिहिलेला

जारीकर्ता तुमच्या नियंत्रणात असेल आणि त्याचे ग्राहक मोजता येत असतील तर साखळी बदला. नियंत्रणात नसेल तर जारीकर्त्याकडे वर करा. पातळी फक्त तारीख आणि मर्यादा असलेला अपवाद म्हणून खाली आणा, ज्यात बदली आधीच नियोजित असेल. बाकी काहीही तेच प्रमाणपत्र तिथे ठेवते आणि जोखीम कमी दिसणाऱ्या ठिकाणी हलवते.

मग स्वच्छ क्लायंटवरून प्रोफाइल पुन्हा तपासा, हँडशेक पूर्ण होतो याची खात्री करा, आणि तरीही अयशस्वी झाल्यास नाकारण्याचा नेमका मजकूर जतन करा. अचूक त्रुटी संदेश पुढील स्तराच्या मालकाला देण्यासारखी सर्वात स्वस्त गोष्ट आहे.