PKCS12, PEM કે DER: VPN ક્લાયન્ટને ખરેખર શું જોઈએ
પેકિંગ નક્કી કરે છે કે તમારો ક્લાયન્ટ ઓળખ આયાત કરે છે કે નહીં, એ નહીં કે તે વિશ્વસનીય છે. PKCS12, PEM અને DER ની તુલના કરો, પછી ચકાસો.
પ્રમાણપત્ર ચર્ચાઓમાં બે દાવા ફરે છે. પહેલો એ કે .p12 મજબૂત વિકલ્પ છે અને .pem ઢીલો; બીજો એ કે ટેક્સ્ટ ફાઇલ મોકલવી સુરક્ષિત હોવી જોઈએ કારણ કે તમે તેને વાંચી શકો છો. બંનેમાંથી કોઈ એક મિનિટની તપાસ પણ ટકતું નથી.
PKCS12, PEM અને DER વર્ણવે છે કે પ્રમાણપત્ર ઑબ્જેક્ટ કેવી રીતે પેક અને એન્કોડ થાય છે. તેઓ નક્કી કરતા નથી કે સામેનો પક્ષ કોણ છે, જારીકર્તા વિશ્વસનીય છે કે નહીં, અથવા ફાઇલને પાસવર્ડની જરૂર છે કે નહીં.
ક્લાયન્ટ શું સ્વીકારે છે તે સુસંગતતાનો પ્રશ્ન છે. ફાઇલમાં શું છે તે ઓળખનો પ્રશ્ન છે. બંનેને અલગ રાખો અને મોટા ભાગની આયાત ભૂલો રહસ્યમય રહેવાનું બંધ કરશે.
ત્રણ કન્ટેનર, એક ઑબ્જેક્ટ મોડેલ
તમારી પાસે ખરેખર શું છે તેનાથી શરૂ કરો. પ્રમાણપત્ર એ જાહેર કી વિશેનું સહી કરેલું નિવેદન છે. ખાનગી કી અલગ સામગ્રી છે જે સાબિત કરે છે કે તમે તે કી નિયંત્રિત કરો છો. સાંકળ એ જારીકર્તાઓનો સમૂહ છે જે તમારું પ્રમાણપત્ર એ મૂળ સાથે જોડે છે જેના પર ક્લાયન્ટ ભરોસો કરે છે. ત્રણેય પેકિંગથી સ્વતંત્ર રીતે અસ્તિત્વ ધરાવે છે.
PKCS12 ફાઇલ, સામાન્ય રીતે .p12 અથવા .pfx, RFC 7292 માં વ્યાખ્યાયિત કન્ટેનર છે જે ખાનગી કી, એક અથવા વધુ પ્રમાણપત્રો અને સાંકળને પાસવર્ડથી સુરક્ષિત એક જ બ્લોકમાં લઈ જઈ શકે છે, સાથે ઓળખનું નામ આપતું એલિયાસ. PEM ફાઇલ RFC 7468 માં વ્યાખ્યાયિત ટેક્સ્ટ ફ્રેમિંગ છે: BEGIN અને END લાઇન વચ્ચે base64 બોડી, અને એક ફાઇલમાં ક્રમમાં અનેક બ્લોક હોઈ શકે. DER એ જ ASN.1 સ્ટ્રક્ચરનું બાઇનરી એન્કોડિંગ છે, અને PEM બોડી શબ્દશઃ base64 માં વીંટાળેલું DER છે.
તે છેલ્લું વાક્ય યાદ રાખવા જેવું છે. PEM ને DER માં રૂપાંતરિત કરવાથી ફ્રેમિંગ ફરી લખાય છે, સામગ્રી નહીં, અને પાછું રૂપાંતરિત કરવાથી મૂળ બાઇટ મળે છે.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
એન્કોડિંગ એ એન્ક્રિપ્શન નથી
base64 એ વહન માટેની મૂળાક્ષરમાળા છે. તે કંઈ છુપાવતું નથી, અને કોઈ પણ શેલમાં PEM બ્લોક ડિકોડ કરી શકે છે. DER ફાઇલ બાઇનરી અને તેટલી જ જાહેર છે. બંને ગુણધર્મમાંથી કોઈ સુરક્ષા નથી, અને કોઈ પાસવર્ડ હોવાનો સંકેત આપતું નથી.
ખરી સુરક્ષા કી સામગ્રીમાં છે. PKCS12 બંડલ તેની સામગ્રીને પાસવર્ડમાંથી મેળવેલી કી હેઠળ એન્ક્રિપ્ટ કરી શકે છે. PEM ખાનગી કીને જૂના હેડર બ્લોકથી એન્ક્રિપ્ટ કરી શકાય છે અથવા PKCS#8 EncryptedPrivateKeyInfo માં રાખી શકાય છે. પ્રમાણપત્ર એકલું કંઈ ગુપ્ત રાખતું નથી, તેથી જે નિકાસ ફક્ત પ્રમાણપત્ર આપે છે તે ક્લાયન્ટને પ્રમાણીકરણ કરવા દેતી નથી, ભલે તમે તેને કોઈ પણ ફોર્મેટમાં લપેટો.
એક્સ્ટેન્શન સંકેત છે, કરાર નહીં. .cer અને .crt માં અંત થતી ફાઇલો બંને એન્કોડિંગમાં દેખાય છે, અને ઉપકરણો DER પ્રમાણપત્રોને .pem નામ હેઠળ એટલી વાર નિકાસ કરે છે કે પ્રત્યય પરથી અનુમાન કરવું એક બપોર વેડફે. તેના બદલે પહેલા બાઇટ વાંચો: PEM ફાઇલ BEGIN લાઇનથી ખૂલે છે, જ્યારે DER 0x30 થી શરૂ થાય છે કારણ કે બાહ્ય સ્ટ્રક્ચર SEQUENCE છે.
આયાત ખરેખર કેમ નિષ્ફળ જાય છે
ક્લાયન્ટની ભૂલ સંદેશાઓ અમાન્ય પ્રમાણપત્ર વિશેના એક વાક્યમાં અનેક ભિન્ન સમસ્યાઓ દબાવે છે, તેથી તેમને કારણ પ્રમાણે અલગ કરો. સૌથી સામાન્ય એન્કોડિંગ અસંગતિ છે: PEM પાર્સ કરતું ક્લાયન્ટ DER ફાઇલ પર પાર્સ ભૂલ આપે છે, અને ઉપાય નવું પ્રમાણપત્ર નહીં પણ રૂપાંતરણ છે. બીજું ગુમ થયેલી કી છે, જ્યાં પ્રમાણપત્ર ઠીક છે અને ઓળખ સાબિત થઈ શકતી નથી. ત્રીજું સાંકળ છે, જ્યાં વચ્ચેના પ્રમાણપત્ર વગરનું બંડલ આયાત સંવાદમાં સાચું દેખાય છે અને હેન્ડશેક દરમિયાન નિષ્ફળ જાય છે.
એન્ક્રિપ્શન પેરામીટર ચોથું કારણ બને છે, અને તે ખોટા પાસવર્ડ જેવું બરાબર દેખાય છે. જૂનાં ઉપકરણો PKCS12 ફાઇલો RC2-40 અને 3DES સાથે નિકાસ કરતાં, જે OpenSSL 3 અસ્વીકારે છે સિવાય કે legacy પ્રદાતા લોડ થયેલો હોય. ઉપકરણમાંથી AES-256-CBC અને PBKDF2 સાથે ફરી નિકાસ એ ટકાઉ ઉપાય છે. એક ફાઇલ માટે ક્લાયન્ટ મશીન પર જૂનાં સાઇફર કાયમ ચાલુ રાખવા ખરાબ સોદો છે.
પાંચમું અસ્પષ્ટતા છે. બે કી અને બે પ્રમાણપત્ર ધરાવતું કન્ટેનર, અથવા ત્રણ CERTIFICATE બ્લોકવાળી PEM ફાઇલ, ક્લાયન્ટને પસંદ કરવા મજબૂર કરે છે, અને તેની પસંદગી ઘણી વાર ફક્ત પહેલી વસ્તુ હોય છે. જ્યારે ટનલ ખોટી ઓળખ સાથે ઉપર આવે છે, ત્યારે સામાન્ય રીતે તે જ કારણ હોય છે.
રૂપાંતરણ પહેલાં નિરીક્ષણ કરો
ગુપ્ત માહિતી છાપ્યા વગર રચના વાંચો. openssl pkcs12 -in bundle.p12 -info -noout એન્ક્રિપ્શન અલ્ગોરિધમ અને એલિયાસની જાણ કરે છે અને કી તથા પ્રમાણપત્રનું આઉટપુટ દબાવે છે, અને openssl-pkcs12 માર્ગદર્શિકા ફ્લેગનું દસ્તાવેજીકરણ કરે છે. -noout કાઢી નાખવું અને -nodes ઉમેરવું એ ફાઇલો બનાવવા માટે છે જે તમે રાખવા માંગો છો, ઝડપી નજર માટે નહીં, કારણ કે તે ખાનગી કી ખુલ્લી રીતે લખે છે.
પ્રમાણપત્ર માટે, openssl x509 -in cert.pem -noout -subject -issuer -dates તેનો જવાબ આપે છે જે આયાત સંવાદ આપશે નહીં, અને -ext subjectAltName ઉમેરવાથી તે નામ દેખાય છે જેના માટે પ્રમાણપત્ર ખરેખર માન્ય છે. જો ફાઇલ DER હોય, તો -inform DER ઉમેરો; તે એક જ ફ્લેગ મોટા ભાગની unable-to-load ભૂલો ઉકેલે છે.
કીને પ્રમાણપત્ર સાથે મેળવવું યાંત્રિક છે, અને કોઈ પણ આયાત પહેલાં કરવા યોગ્ય છે:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
સમાન ડાયજેસ્ટનો અર્થ છે કે જોડી એકબીજા સાથે છે. ભિન્ન ડાયજેસ્ટનો અર્થ છે કે તમારી પાસે ખોટી કી છે, અને કોઈ ફોર્મેટ રૂપાંતરણ તેને બદલશે નહીં.
ફોર્મેટ કદીય ન બદલે તે
વિશ્વાસના નિર્ણય કન્ટેનરની ઉપર લેવાય છે. ક્લાયન્ટ તેના સ્ટોરમાંના મૂળ સુધી સાંકળ ચાલે છે, માન્યતા વિન્ડો તપાસે છે, ક્લાયન્ટ પ્રમાણીકરણ માટે વિસ્તૃત કી વપરાશ તપાસે છે, અને સર્વર બાજુ તપાસે છે કે તેણે ડાયલ કરેલું નામ પ્રમાણપત્રમાં છે. આ પગલાંમાંથી કોઈ ફાઇલ એક્સ્ટેન્શન વાંચતું નથી.
તેથી જ ભૂલ નામ પર ન લાગે ત્યાં સુધી ફાઇલનું નામ બદલવું સમય વેડફવાની એટલી વિશ્વસનીય રીત છે. આયાત સફળ થાય છે, ઓળખ તોય ખોટી રહે છે, અને નિષ્ફળતા હેન્ડશેક દરમિયાન પાછી આવે છે જ્યાં સંદેશ ઓછો મદદરૂપ હોય છે. તેથી જ બે વર્ષ પહેલાં નિકાસ કરેલું બંડલ ચોખ્ખું આયાત થાય છે અને તોય નકારાય છે: સમાપ્તિ તારીખ ફાઇલના નામમાં નહીં, પ્રમાણપત્રની અંદર મુસાફરી કરી હતી.
ફરી કામ ટાળતો ક્રમ
ક્લાયન્ટના દસ્તાવેજીકરણને પૂછો કે કયા એન્કોડિંગ સ્વીકારે છે અને ક્લાયન્ટ ઓળખ માટે કયું કન્ટેનર અપેક્ષિત છે, પછી જુઓ કે તમને શું આપવામાં આવ્યું. જો ક્લાયન્ટને એક આયાતયોગ્ય ઓળખ જોઈએ અને તમારી પાસે અલગ PEM ફાઇલો હોય, તો તમે નિયંત્રિત કરો તેવા પાસવર્ડ સાથે એક વાર બંડલ બનાવો અને સ્રોત રાખો. જો PEM જોઈએ, તો કી અને સાંકળ કાઢો, અને પછી તમારી ટીમ પહેલેથી વાપરતી ક્રેડેન્શિયલ હેન્ડલિંગ પ્રક્રિયા દ્વારા વચ્ચેની ફાઇલો દૂર કરો.
આયાત પછી, સંવાદને નહીં પણ ઓળખ ચકાસો: વિષય, જારીકર્તા, સમાપ્તિ અને ક્લાયન્ટ જે નામ રજૂ કરશે. સૂચિમાંનું મૈત્રીપૂર્ણ નામ લેબલ છે, ચકાસાયેલી ઓળખ નહીં. જો પછી ટનલ નિષ્ફળ જાય, તો તમે પેકિંગને બદલે પ્રમાણીકરણ કે રૂટિંગ ડિબગ કરી રહ્યા છો, જે ઘણી ટૂંકી વાતચીત છે.