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 ग्राहकले विश्वास गर्ने दायरा चुपचाप फराकिलो बनाउँछ।

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

निर्णय, नियमका रूपमा लेखिएको

जारीकर्ता तपाईंको नियन्त्रणमा छ र त्यसका उपभोक्ता गन्न सकिन्छ भने चेन बदल्नुहोस्। नियन्त्रणमा छैन भने जारीकर्तासम्म पुर्याउनुहोस्। स्तर केवल मिति र सीमासहितको अपवादका रूपमा घटाउनुहोस्, जसमा प्रतिस्थापन पहिले नै तालिकामा छ। अरू जे गरे पनि त्यही प्रमाणपत्र त्यहीँ रहन्छ र जोखिम कम देखिने ठाउँमा सर्छ।

त्यसपछि सफा ग्राहकबाट प्रोफाइल फेरि परीक्षण गर्नुहोस्, ह्यान्डसेक पूरा भएको पुष्टि गर्नुहोस्, र अझै असफल भए अस्वीकारको ठ्याक्कै पाठ राख्नुहोस्। सटीक त्रुटि सन्देश अर्को तहको मालिकलाई दिन सकिने सबैभन्दा सस्तो कुरा हो।