जुनी 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 क्लायंट पर्यावरणाबाहेर ठेवणे हाच मुद्दा आहे: त्याच्यासह मोजा, त्याशिवाय वितरित करा आणि खाजगी की डिस्कवर संरक्षित ठेवा।