സ്വകാര്യ കീ ഇല്ലാതെ P12-ൽ നിന്ന് സർട്ടിഫിക്കറ്റുകൾ കയറ്റുമതി ചെയ്യുക

സപ്പോർട്ട് ടിക്കറ്റ് VPN ബണ്ടിലിനുള്ളിൽ ഏത് സർട്ടിഫിക്കറ്റ് ഉണ്ടെന്ന് ചോദിക്കുന്നു, ആദ്യ പ്രേരണ എല്ലാം കയറ്റുമതി ചെയ്ത് അറ്റാച്ച് ചെയ്യുകയാണ്. P12 ഫയൽ സർട്ടിഫിക്കറ്റുകളും സ്വകാര്യ കീ മെറ്റീരിയലും ഒരൊറ്റ കണ്ടെയ്നറിൽ പായ്ക്ക് ചെയ്യുന്നു, അതിനാൽ എല്ലാം കയറ്റുമതി ചെയ്യുന്നത് നിങ്ങൾ അയയ്ക്കരുതാത്തതു തന്നെ. ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന കമാൻഡ് തിരഞ്ഞെടുപ്പിന്റെ പ്രശ്നമാണ്, പരിവർത്തനത്തിന്റെയല്ല. കണ്ടെയ്നറിന്റെ ഏത് പകുതി ലഭിക്കുമെന്ന് നാല് ഫ്ലാഗുകൾ തീരുമാനിക്കുന്നു, അവയിൽ രണ്ടെണ്ണം യഥാർത്ഥത്തിലുള്ളതിനേക്കാൾ സുരക്ഷിതമായി തോന്നുന്നു.

കണ്ടെയ്നർ ശൂന്യമാക്കുന്നതിന് പകരം വായിക്കാൻ തുടങ്ങുക.

PKCS12 ഫയൽ യഥാർത്ഥത്തിൽ എന്താണ് വഹിക്കുന്നത്

PKCS12 കണ്ടെയ്നർ ഒന്നോ അതിലധികമോ സർട്ടിഫിക്കറ്റുകൾ, ഒരുപക്ഷേ ഒരു സ്വകാര്യ കീ, ഒപ്പം ഉള്ളടക്കത്തിന് മേലെ ഒരു message authentication code എന്നിവ വഹിക്കുന്നു. സർട്ടിഫിക്കറ്റുകളിൽ നിങ്ങളുടെ ക്ലയന്റ് ഐഡന്റിറ്റിയുടെ ലീഫ് സർട്ടിഫിക്കറ്റും അതിനെ CA-യുമായി ബന്ധിപ്പിക്കുന്ന ഇന്റർമീഡിയറ്റ് സർട്ടിഫിക്കറ്റുകളും ഉൾപ്പെടാം. കീ ഉള്ളപ്പോൾ, ഫയലിനെ രേഖയാക്കാതെ രഹസ്യമാക്കുന്നത് അതാണ്.

ഈ വ്യത്യാസമാണ് -nokeys ഉള്ളതിനും ഈ ജോലിക്ക് ആവശ്യമായ ഫ്ലാഗ് അതു തന്നെ ആകാനും കാരണം.

കീ എഴുതാതെ ബണ്ടിൽ വായിക്കുക

പരിശോധനാ രൂപം ഘടനയും അൽഗോരിതം വിശദാംശങ്ങളും പ്രിന്റ് ചെയ്യുന്നു, ഒന്നും എഴുതുന്നില്ല: openssl pkcs12 -in client.p12 -info -noout. ഇത് ഇംപോർട്ട് പാസ്വേഡ് ആവശ്യപ്പെടുന്നു, ആ മൂല്യത്തിന് അതാണ് ശരിയായ സ്ഥലം, ഫയലിൽ കീ ഉണ്ടോ എന്നും പറയുന്നു. പാസ്വേഡ് ടൈപ്പ് ചെയ്യാൻ കഴിയാത്തപ്പോൾ -passin env:PKCS12_PASS ഉപയോഗിക്കുക, കാരണം shell കമാൻഡിലെ പാസ്വേഡ് പ്രോസസ് പട്ടികയിലെ പാസ്വേഡാണ്. ഈ ഘട്ടം ഒന്നും കയറ്റുമതി ചെയ്യുന്നില്ല, അതാണ് മുഴുവൻ കാര്യം.

ഔട്ട്പുട്ട് മൂന്ന് കാര്യങ്ങൾക്കായി വായിക്കുക: എത്ര സർട്ടിഫിക്കറ്റുകൾ, കീ ഉണ്ടോ, ഏത് അൽഗോരിതങ്ങൾ അതിനെ സംരക്ഷിക്കുന്നു.

-nokeys ഉപയോഗിക്കുക, അതിനെ -nocerts-മായി കൂട്ടിക്കലർത്തരുത്

-nokeys സ്വകാര്യ കീകൾ ഒഴിവാക്കി സർട്ടിഫിക്കറ്റുകൾ വിടുന്നു. -clcerts അതിനെ ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകളിലേക്ക് ചുരുക്കുന്നു, -cacerts അതിനെ CA സർട്ടിഫിക്കറ്റുകളിലേക്ക് ചുരുക്കുന്നു, ഇവ രണ്ടും ഫിൽട്ടറുകളാണ്, ബദലുകളല്ല. -nocerts അതേ ആശയത്തിന്റെ സുരക്ഷിത അക്ഷരവിന്യാസം പോലെ വായിക്കപ്പെടുന്നു, വിപരീതം സൂചിപ്പിക്കുന്നു: സർട്ടിഫിക്കറ്റുകളില്ല, ഇത് കീകൾ മാത്രം വിടുന്നു. അതിനെ സർട്ടിഫിക്കറ്റ് കയറ്റുമതിയിൽ കലർത്തുന്നതാണ് സ്വകാര്യ കീ ഡിസ്കിൽ എത്തുന്ന വഴി.

സർട്ടിഫിക്കറ്റ് ഫയലും CA ഫയലും, മറ്റൊന്നുമല്ലാതെ ഉണ്ടാക്കുന്ന രണ്ട് വരി രൂപം ഇതാണ്:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

പഴയ ബണ്ടിലുകൾക്ക് OpenSSL 3-ൽ -legacy ആവശ്യമാണ്, അവയുടെ പഴയ എൻക്രിപ്ഷൻ വായിക്കാൻ. ആ ഫ്ലാഗ് പാഴ്സർ എന്ത് സ്വീകരിക്കുന്നു എന്ന് മാറ്റുന്നു, എന്ത് പുറപ്പെടുവിക്കുന്നു എന്നല്ല. പാഴ്സിംഗ് പിന്തുണയില്ലാത്ത അൽഗോരിതം പിശകിനാൽ പരാജയപ്പെട്ടാൽ, -legacy ചേർക്കുന്നതാണ് ശരിയായ ആദ്യ നടപടി, MAC പരിശോധന ഒഴിവാക്കുന്നതല്ല.

ഔട്ട്പുട്ട് പരിശോധിക്കുക, എക്സിറ്റ് കോഡല്ല

പൂജ്യം എക്സിറ്റ് നില കമാൻഡ് പ്രവർത്തിച്ചു എന്ന് പറയുന്നു, ഫയലിൽ നിങ്ങൾ പ്രതീക്ഷിക്കുന്നത് ഉണ്ട് എന്നല്ല. ഔട്ട്പുട്ടിലെ സർട്ടിഫിക്കറ്റുകൾ എണ്ണി subject-ഉം തീയതികളും വായിക്കുക: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. ഫിംഗർപ്രിന്റ് സപ്പോർട്ട് ടീം പ്രതീക്ഷിക്കുന്നതുമായി താരതമ്യം ചെയ്യുക, കാരണം രണ്ട് ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകളുള്ള ബണ്ടിൽ രണ്ട് ബ്ലോക്കുള്ള ഫയൽ ഉണ്ടാക്കുന്നു, മിക്ക ഉപകരണങ്ങളും ആദ്യത്തേത് മാത്രം വായിക്കുന്നു. ഉദ്ദേശ്യം, വിശ്വാസം, കീ പൊരുത്തം എന്നിവ വീണ്ടും വെവ്വേറെ പരീക്ഷണങ്ങളാണ്.

പാഴ്സ് ചെയ്യാവുന്ന സർട്ടിഫിക്കറ്റ് പാഴ്സ് ചെയ്യാവുന്ന സർട്ടിഫിക്കറ്റാണ്. അത് VPN സ്വീകരിക്കുന്ന സർട്ടിഫിക്കറ്റല്ല.

നിങ്ങൾക്ക് ഫയലുകൾ ആവശ്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക

സ്വീകരിക്കുന്ന ക്ലയന്റ് PKCS12 നേരിട്ട് ഇംപോർട്ട് ചെയ്യുന്നുവെങ്കിൽ, യഥാർത്ഥ ബണ്ടിൽ അംഗീകൃത ചാനലിലൂടെ പാസ്വേഡ് വേർതിരിച്ച് വച്ച് അയയ്ക്കുന്നത് എളുപ്പമാണ്, സംരക്ഷണവും നിലനിർത്തുന്നു. എക്സ്ട്രാക്ഷൻ പരിശോധനയ്ക്ക്, PEM ആവശ്യമുള്ള ക്ലയന്റിന്, അല്ലെങ്കിൽ നിർദ്ദിഷ്ട ആർട്ടിഫാക്ട് ആവശ്യപ്പെട്ട സപ്പോർട്ട് കേസിന്. ഓരോ എക്സ്ട്രാക്ഷനും ഒരു പാളി നീക്കുന്നു, അതിന് കാരണം ഉണ്ടായിരിക്കണം.

പൊതു സർട്ടിഫിക്കറ്റുകളിൽ സ്വകാര്യ കീ ഇല്ല, പക്ഷേ പേരുകളും സ്ഥാപന വിശദാംശങ്ങളും ഉണ്ട്. ഫയലിന് പകരം ടിക്കറ്റ് ആവശ്യപ്പെട്ട ഫീൽഡുകൾ പങ്കിടുക, ഫയൽ തന്നെ ആവശ്യപ്പെട്ടിട്ടില്ലെങ്കിൽ.