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 प्रदाता को हटा दे, तो वह परीक्षण फिर चलाएँ ताकि दिखे कि कुंजी को अभी भी उसकी ज़रूरत है या प्रोफ़ाइल को इस अस्थायी उपाय से हटाया जा सकता है।

संकेत कम से कम तीन कारणों वाला लक्षण है, और उनमें से केवल एक ही गुम पासफ़्रेज़ है।