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 प्रदाता काढला, तर ती चाचणी पुन्हा चालवा आणि किल्लीला अजूनही त्याची गरज आहे का किंवा प्रोफाइल या तात्पुरत्या उपायातून बाहेर काढता येईल का ते पहा।

प्रॉम्प्ट हे किमान तीन कारणे असलेले लक्षण आहे, आणि त्यातील फक्त एकच गहाळ पासफ्रेज आहे।