पुरानो P12 फाइल OpenSSL 3 मा असफल: गलत पासफ्रेज कि पुरानो साइफर?
गलत टाइप गरिएको पासफ्रेजलाई OpenSSL 3 ले खोल्न नमान्ने पुरानो RC2 बन्डलबाट छुट्याउनुहोस्, त्यसपछि कुञ्जी संरक्षण नहटाई फाइल पुनः सिल गर्नुहोस्।
आयात संवादले तपाईंको पासवर्ड लिन्छ, एकछिन घुम्छ र त्यसपछि बन्डल पढ्न सक्दिन भन्छ। तपाईंले पासफ्रेज गलत टाइप गर्नुभयो कि फाइल ग्राहकले अब नदिने साइफरले सिल गरिएको हो, त्यो सन्देशमा केही पनि भन्दैन। यी फरक असफलता र फरक समाधान हुन्, गलत छनोटले ग्राहक डाउनग्रेडतर्फ लैजान्छ जसले निर्णय मात्र पछि सार्छ। ग्राहक कुन चरणमा रोकिन्छ हेर्दा करिब एक मिनेटमा ती छुट्टिन्छन्।
संवाद र प्रमाणपत्र सूचीबीच के हुन्छ
.p12 फाइल एउटा कन्टेनर हो, प्रमाणपत्र होइन। भित्र एक वा बढी प्रमाणपत्र झोला र तपाईंको पासवर्डबाट निकालिएको कुञ्जीले इन्क्रिप्ट गरिएको निजी कुञ्जी झोला, साथै सम्पूर्ण फाइलमा MAC भनिने अखण्डता जाँच हुन्छ। त्यो खोल्नु भनेको त्यो MAC जाँच्नु, कुञ्जी झोला डिक्रिप्ट गर्नु र प्रमाणपत्रलाई बाहिर आउने कुञ्जीसँग मिलाउनु हो।
पासवर्डको समस्या MAC चरणमा आउँछ। साइफरको समस्या पछि आउँछ, जब कुञ्जी झोला खोल्नुपर्छ र खोल्ने बिल्डमा फाइलमा उल्लेख गरिएको एल्गोरिदमको कार्यान्वयन हुँदैन।
दोस्रो अवस्था आजका प्रणालीमा सामान्य छ किनकि OpenSSL 3 ले पुराना एल्गोरिदमको समूह वैकल्पिक legacy provider मा सार्यो। 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 provider लाई त्यही एक प्रक्रियाका लागि मात्र लोड गर्छ। यसले 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 सन्दर्भ ले यहाँ प्रयोग गरिएका provider, पासफ्रेज र आउटपुट विकल्प सूचीबद्ध गर्छ। legacy provider लाई ग्राहक वातावरणबाहिर राख्नु नै मुख्य कुरा हो: त्यससँग मापन गर्नुहोस्, त्योबिना पठाउनुहोस् र निजी कुञ्जीलाई डिस्कमा संरक्षित राख्नुहोस्।