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 क्लाइंट किस पर भरोसा करेगा।

अपवाद को स्वामी और हटाने के चरण के साथ लिखिए। दस्तावेज़ न किया गया स्तर परिवर्तन छह महीने बाद गलती से अलग नहीं पहचाना जा सकता, और अगला इंजीनियर नहीं जानेगा कि यह कभी निर्णय था।

निर्णय, नियम के रूप में लिखा गया

जब जारीकर्ता आपके नियंत्रण में हो और आप उसके उपभोक्ताओं की सूची बना सकें तब श्रृंखला बदलिए। न हो तो जारीकर्ता तक एस्केलेट कीजिए। स्तर केवल तिथि-युक्त, सीमित अपवाद के रूप में घटाइए, बदलाव पहले से निर्धारित हो। बाकी कुछ भी वही प्रमाणपत्र जगह पर छोड़ता है और जोखिम को कम दिखने वाली जगह ले जाता है।

फिर स्वच्छ क्लाइंट से प्रोफ़ाइल दोबारा जाँचिए, पुष्टि कीजिए कि हैंडशेक पूरा होता है, और अगर अब भी विफल हो तो अस्वीकृति का सटीक पाठ रखिए। सटीक त्रुटि संदेश अगली परत के स्वामी को देने योग्य सबसे सस्ती चीज़ है।