पुरानी P12 OpenSSL 3 पर विफल: गलत पासवर्ड या पुराना साइफ़र?
गलत टाइप किए गए पासफ़्रेज़ को OpenSSL 3 द्वारा खोलने से इनकार किए गए पुराने RC2 बंडल से अलग पहचानें, फिर कुंजी सुरक्षा हटाए बिना फ़ाइल को फिर से सील करें।
आयात संवाद आपका पासवर्ड लेता है, एक पल घूमता है और फिर कहता है कि वह बंडल नहीं पढ़ सकता। उस संदेश में कुछ भी नहीं बताता कि आपने पासफ़्रेज़ गलत टाइप किया है या फ़ाइल ऐसे साइफ़र से सील की गई है जो क्लाइंट अब नहीं देता। ये अलग-अलग विफलताएँ हैं अलग-अलग समाधानों के साथ, और गलत चुनाव क्लाइंट को डाउनग्रेड करने की ओर ले जाता है जो केवल निर्णय को टालता है। क्लाइंट किस चरण पर रुकता है, यह देखकर आप उन्हें लगभग एक मिनट में अलग कर सकते हैं।
संवाद और प्रमाणपत्र सूची के बीच क्या होता है
.p12 फ़ाइल एक कंटेनर है, प्रमाणपत्र नहीं। इसके अंदर एक या अधिक प्रमाणपत्र बैग और एक निजी-कुंजी बैग है जो आपके पासवर्ड से प्राप्त कुंजी से एन्क्रिप्ट है, साथ ही पूरी फ़ाइल पर MAC नामक अखंडता जाँच है। इसे खोलने का अर्थ है उस MAC को सत्यापित करना, कुंजी बैग को डिक्रिप्ट करना और प्रमाणपत्र को उस कुंजी से मिलाना जो उससे बाहर आती है।
पासवर्ड की समस्या MAC चरण पर आती है। साइफ़र की समस्या बाद में आती है, जब कुंजी बैग को खोलना होता है और खोलने वाला बिल्ड फ़ाइल में नामित एल्गोरिदम का कोई कार्यान्वयन नहीं रखता।
दूसरा मामला आज के सिस्टम पर सामान्य है क्योंकि OpenSSL 3 ने पुराने एल्गोरिदम के एक समूह को वैकल्पिक legacy प्रदाता में स्थानांतरित कर दिया। OpenSSL 1.x द्वारा निर्यात किए गए बंडल आमतौर पर प्रमाणपत्रों को 40-बिट RC2 से और निजी कुंजी को तीन-कुंजी Triple DES से सील करते थे। डिफ़ॉल्ट OpenSSL 3 बिल्ड अभी भी आपके सही पासवर्ड से MAC सत्यापित करता है और फिर बैग पर विफल हो जाता है, इसलिए पासवर्ड कभी गलत नहीं था और उसे फिर से टाइप करने से कुछ नहीं बदलता।
कुंजी लिखे बिना कंटेनर पढ़ें
अपनी मशीन पर मौजूद OpenSSL बिल्ड से फ़ाइल को पार्स करने और वह बिंदु पढ़ने को कहें जहाँ वह हार मानता है। बिना आउटपुट फ़ाइल के निरीक्षण कुंजी को डिस्क पर एन्क्रिप्टेड छोड़ देता है, और साझा होस्ट पर यह चरण सुरक्षित होने का यही एकमात्र कारण है।
openssl pkcs12 -in vpn-identity.p12 -info -nooutसही पासवर्ड वाले पुराने बंडल पर यह बैग विशेषताएँ छापता है और फिर digital envelope routines::unsupported के साथ रुक जाता है। गलत पासवर्ड से कोई भी बैग पढ़े जाने से पहले आपको Mac verify error: invalid password? मिलता है। दोनों संदेश विपरीत दिशाओं में इशारा करते हैं, और यही वह जानकारी है जो क्लाइंट ने छिपाई थी।
यदि विफलता असमर्थित-एल्गोरिदम वाली है, तो वही कमांड फिर चलाएँ, केवल -legacy जोड़कर और बाकी कुछ न बदलकर। वह फ़्लैग केवल उसी प्रक्रिया के लिए legacy प्रदाता लोड करता है। यह VPN क्लाइंट को पुराने बंडल पार्स करने पर मजबूर नहीं करता, सिस्टम-व्यापी क्रिप्टो नीति को नहीं छूता, और यह मरम्मत नहीं बल्कि माप है, क्योंकि फ़ाइल फिर भी बदलनी होगी।
कौन-सी त्रुटि किस चरण को दर्शाती है
एक छोटी तालिका तीन परिणामों को अलग रखती है, और शब्दावली इससे अधिक मायने रखती है कि संवाद कहाँ दिखा।
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data या header too long जैसा पाठ पहले दो समूहों में से किसी में नहीं आता। यह प्रारूप की समस्या है: .pem नाम दी गई DER फ़ाइल, पंक्ति-अंत फिर से लिखने वाले संपादक द्वारा बिगाड़ी गई प्रति, या अधूरा डाउनलोड। साइफ़र देखना शुरू करने से पहले चेकसम की तुलना जारीकर्ता द्वारा भेजे गए चेकसम से करें।
Mac verify error को केवल पासवर्ड के बारे में साक्ष्य मानें। इसका अर्थ है कि आपके टाइप किए गए से गणना किया गया MAC संग्रहीत मान से मेल नहीं खाता, जो टाइपो, पहले के आयात से कैश किए गए पासवर्ड, या भिन्न पासफ़्रेज़ के अंतर्गत फिर से निर्यात की गई फ़ाइल से होता है। यह इस बारे में कुछ नहीं कहता कि अंदर के एल्गोरिदम पुराने हैं या नहीं।
ऐसा बंडल बनाएँ जिसे क्लाइंट वास्तव में खोल सके
जब legacy पार्सर पुष्टि कर दे कि फ़ाइल ठीक है, तो स्थायी समाधान ऐसा प्रतिस्थापन है जिसके एल्गोरिदम लक्ष्य क्लाइंट समर्थन करता है: कुंजी और प्रमाणपत्र बैग के लिए AES-256-CBC, व्युत्पत्ति के लिए SHA-256 के साथ PBKDF2, और MAC के लिए SHA-256। आपका PKI प्रशासक इसे उसी कुंजी सामग्री से निर्यात कर सकता है, और अंदर का प्रमाणपत्र वही रहता है जिस पर आपके सर्वर पहले से भरोसा करते हैं।
जब आपको स्थानीय रूप से परिवर्तित करना हो, तो pkcs12 टूल से बैग को पहले डंप करने के बजाय फिर से सील करने को कहें। दोनों पासफ़्रेज़ को फ़ाइल से पढ़कर अपने शेल इतिहास से बाहर रखें।
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passसफल रूपांतरण समाप्ति, कुंजी उपयोग, निजी-कुंजी मिलान या सर्वर के जारीकर्ता श्रृंखला पर भरोसे के बारे में कुछ नहीं कहता। फिर से पैकेजिंग एक परिवहन परिवर्तन है, नवीनीकरण नहीं, और उनमें से प्रत्येक को अभी भी अपनी जाँच चाहिए।
ऐसी किसी भी विधि को छोड़ दें जो असुरक्षित मध्यवर्ती कुंजी लिखती है या खाली आउटपुट पासवर्ड देती है, केवल इसलिए कि क्लाइंट ने बाद में फ़ाइल स्वीकार कर ली। सुरक्षा हटाए गए पठनीय बंडल का परिणाम उस आयात विफलता से बुरा है जिससे आपने शुरुआत की थी।
पुष्टि करें कि क्लाइंट ने वही फ़ाइल आयात की जो आपने बनाई
टर्मिनल में साफ़ पार्स सिद्ध करता है कि कंटेनर वैध है। यह सिद्ध नहीं करता कि क्लाइंट ने इसे चुना, क्योंकि बचा हुआ प्रोफ़ाइल पुरानी फ़ाइल की ओर इशारा करता रह सकता है, और कुछ क्लाइंट आयातित पहचान को ऐसे नाम के अंतर्गत कैश करते हैं जो आपने नहीं चुना।
जिस पहचान को आप आयात करने वाले हैं उसे छापें और क्लाइंट अपने प्रमाणपत्र दृश्य में जो दिखाता है उससे तुलना करें।
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256पहले पुरानी प्रोफ़ाइल प्रविष्टि हटाएँ, फिर आयात करें। यदि क्लाइंट लोड किए गए विषय या फ़िंगरप्रिंट को लॉग करता है, तो उसे ऊपर की पंक्ति से मिलाएँ; यदि वह केवल मैत्रीपूर्ण नाम दिखाता है, तो इसके बजाय समाप्ति तिथि जाँचें, क्योंकि उसे उसी जारीकर्ता के किसी अन्य प्रमाणपत्र से भ्रमित करना कठिन है।
PKCS12 संदर्भ यहाँ प्रयुक्त प्रदाता, पासफ़्रेज़ और आउटपुट विकल्पों की सूची देता है। बात यह है कि legacy प्रदाता को क्लाइंट परिवेश से बाहर रखें: उसके साथ मापें, उसके बिना भेजें, और निजी कुंजी को डिस्क पर सुरक्षित रखें।