જૂનું 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 પ્રદાતાને ક્લાયન્ટ પર્યાવરણની બહાર રાખવાનો છે: તેની સાથે માપો, તેના વિના મોકલો, અને ખાનગી કીને ડિસ્ક પર સુરક્ષિત રાખો.