OpenSSL 3 पछि OpenVPN कुञ्जी प्रम्प्ट: प्रदायक जाँच्नुहोस्

कसैले प्रोफाइल छोएको छैन, तैपनि त्यही क्लाइन्टले अब हरेक पटक सुरु हुँदा निजी कुञ्जीको लागि पासफ्रेज माग्छ। जब यो परिवर्तन वितरण अपग्रेडको केही दिनभित्र आउँछ, अपग्रेड नै सम्भावित कारण हो: OpenSSL 3 ले आफ्नो एल्गोरिदम समर्थन पुनर्गठन गर्यो, र पुरानो लाइब्रेरीले सजिलै पढ्ने कुञ्जी एउटै बाइट नबदली अपठनीय हुन सक्छ। जाँचहरू क्रममा गर्नुहोस्, किनकि प्रम्प्ट मात्र हेर्दा तीमध्ये दुई समान देखिन्छन्।

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

कुञ्जी इन्क्रिप्ट गरिएको छ कि छैन जाँच्नुहोस्

फाइलको पहिलो लाइन पढ्नुहोस् र त्यसपछि लाइब्रेरीलाई यसलाई पार्स गर्न दिनुहोस्, किनकि फाइलको नामले केही प्रमाणित गर्दैन। लेबल भएको PEM ब्लक ENCRYPTED PRIVATE KEY इन्क्रिप्टेड PKCS#8 हो, र पुरानो RSA PRIVATE KEY ब्लक जसमा Proc-Type: 4,ENCRYPTED छ त्यो परम्परागत रूप हो, र दुवैले पासफ्रेजको अपेक्षा गर्छन्। इन्क्रिप्ट नगरिएको PRIVATE KEY ब्लकले त त्यो कदापि माग्नु हुँदैन। फाइलको मालिक खाताबाट पार्सिङ चलाउनुहोस्, किनकि अनुमति समस्या फरक र धेरै कम रोचक त्रुटि दिन्छ।

यदि कुञ्जी साँच्चै इन्क्रिप्ट गरिएको छैन र क्लाइन्ट अझै सोध्छ भने, क्रिप्टोग्राफी हेर्न छोड्नुहोस् र प्रोफाइलले सेवाले अझै पढ्न सक्ने askpass फाइलको नाम दिन्छ कि भनी जाँच्नुहोस्।

यो बिल्डले यसलाई डिक्रिप्ट गर्न सक्छ कि जाँच्नुहोस्

OpenSSL 3 ले आफ्नो एल्गोरिदम समर्थन प्रदायकहरूमा विभाजन गर्यो, र पुराना साइफरहरूको समूह अब डिफल्ट प्रदायकको सट्टा legacy प्रदायकमा छ। ती साइफरमध्ये एउटाले इन्क्रिप्ट गरिएको कुञ्जी वैध रहन्छ, तर legacy प्रदायक बिना लोड गरिएको लाइब्रेरीले यसलाई डिकोड गर्न सक्दैन। केही क्लाइन्टमा यो दोहोरिने प्रम्प्टको रूपमा देखिन्छ, अरूमा पासफ्रेजकै ठीक पछि कठोर असफलताको रूपमा।

उही कुञ्जी उही बाइनरीले दुई पटक पार्स गर्नुहोस्: पहिले डिफल्ट प्रदायक मात्र, त्यसपछि कमाण्ड लाइनमा legacy र डिफल्ट दुवै मागेर। पहिलो असफल भएको ठाउँमा दोस्रो सफल भयो भने, निदान अपग्रेडको समयमा होइन प्रमाणमा टिक्छ। दुवै समान रूपमा असफल भए भने, पासफ्रेज गलत छ वा फाइल बिग्रेको छ, र कुनै पनि प्रदायक सेटिङले दुवैमध्ये केही सुधार्दैन।

उपलब्ध सबैभन्दा साँघुरो समाधान जाँच्नुहोस्

प्रणाली-व्यापी परिवर्तनभन्दा क्लाइन्टमा सीमित परिवर्तनलाई प्राथमिकता दिनुहोस्। केही 2.6 बिल्डहरूले त्यो डेमन प्रक्रियाको लागि दुवै प्रदायक लोड गर्ने प्रोफाइल विकल्प स्वीकार्छन्, त्यसैले त्यसमा भर पर्नु अघि तपाईंको ठ्याक्कै संस्करणको म्यानुअलमा निर्देशन पुष्टि गर्नुहोस्; यसको सट्टा प्रणालीको openssl.cnf सम्पादन गर्दा होस्टमा भएका हरेक OpenSSL प्रोग्राममा असर पर्छ। कुञ्जी पुनः इन्कोड भएपछि साँघुरो सेटिङ फर्काउन पनि धेरै सजिलो हुन्छ।

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

सेवाको सन्दर्भ जाँच्नुहोस्, त्यसपछि पुनः इन्कोड गर्नुहोस्

कुञ्जी खोल्न सकिने भएपछि, यसलाई आधुनिक एल्गोरिदमले पुनः इन्क्रिप्ट गर्नुहोस् ताकि निर्भरता हराउनेछ। नयाँ फाइल आधुनिक साइफरले लेख्नुहोस्, यो पार्स हुन्छ कि जाँच्नुहोस्, प्रोफाइल अद्यावधिक गर्नुहोस्, र पुरानो प्रतिलिपि जडान सफल नभएसम्म मात्र राख्नुहोस्। पासफ्रेज कहिल्यै कमाण्ड लाइनमा नराख्नुहोस्, जहाँ जोकोही स्थानीय प्रयोगकर्ताले प्रक्रिया सूचीबाट पढ्न सक्छ। पुरानो फाइल नयाँले सेवा खाताबाट जोडिएपछि मात्र हटाउनुहोस्, तपाईंको शेलबाट मात्र होइन।

त्यसपछि क्लाइन्ट वास्तवमै चलाउने युनिट जाँच्नुहोस्। तपाईंको शेलमा पढ्न सकिने कुञ्जी अर्को खातामुनि वा कठोर बनाइएको गृह डाइरेक्टरी सेटिङसहित चल्ने सेवाको लागि अपठनीय हुन सक्छ।

प्रोफाइलको छेउमा प्रदायक सेटिङ अभिलेख गर्नुहोस् र दुई-कमाण्ड परीक्षण साथै राख्नुहोस्। पछि कुनै अपग्रेडले legacy प्रदायक हटाए, त्यो परीक्षण फेरि चलाउनुहोस् र कुञ्जीलाई अझै त्यसको आवश्यकता छ कि प्रोफाइललाई यो अस्थायी उपायबाट बाहिर निकाल्न सकिन्छ भनी हेर्नुहोस्।

प्रम्प्ट कम्तीमा तीन कारण भएको लक्षण हो, र तीमध्ये एउटा मात्र हराएको पासफ्रेज हो।