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 എന്നിവയോടെ എക്സ്പോർട്ട് ചെയ്തിരുന്നു, legacy പ്രൊവൈഡർ ലോഡ് ചെയ്യാതെ OpenSSL 3 അവ നിരസിക്കുന്നു. ഉപകരണത്തിൽ നിന്ന് 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 വേണമെങ്കിൽ, കീയും ചെയിനും വേർതിരിച്ചെടുത്ത്, പിന്നീട് ഇന്റർമീഡിയറ്റ് ഫയലുകൾ നിങ്ങളുടെ ടീം ഇതിനകം ഉപയോഗിക്കുന്ന ക്രെഡൻഷ്യൽ കൈകാര്യം ചെയ്യൽ പ്രക്രിയയിലൂടെ നീക്കം ചെയ്യുക.
ഇംപോർട്ടിന് ശേഷം ഡയലോഗല്ല, ഐഡന്റിറ്റി പരിശോധിക്കുക: വിഷയം, ഇഷ്യൂവർ, കാലാവധി, ക്ലയന്റ് അവതരിപ്പിക്കുന്ന പേര്. ലിസ്റ്റിലെ സൗഹൃദപരമായ പേര് ഒരു ലേബലാണ്, പരിശോധിച്ച ഐഡന്റിറ്റിയല്ല. പിന്നീട് ടണൽ പരാജയപ്പെട്ടാൽ, നിങ്ങൾ പായ്ക്കിംഗിന് പകരം പ്രാമാണീകരണമോ റൂട്ടിംഗോ ഡീബഗ് ചെയ്യുകയാണ്, അത് വളരെ ചെറിയ സംഭാഷണമാണ്.