പരിവർത്തനം ചെയ്യുന്നതിന് മുമ്പ്: SSH കീയും OpenVPN സർട്ടിഫിക്കറ്റും

സർട്ടിഫിക്കറ്റ് പിശകോടെ ഇറക്കുമതി പരാജയപ്പെടുന്നു, അതിനാൽ വ്യക്തമായ നടപടി പരിവർത്തനം പോലെ തോന്നുന്നു. ആ പ്രവണത ആളുകളെ ഫയൽ എക്സ്റ്റൻഷൻ മാറുന്ന, പക്ഷേ നിരസിക്കൽ അതേപടി തുടരുന്ന ഒരു വഴിയിലേക്ക് നയിക്കുന്നു. authorized_keys-ലെ ssh-ed25519 ലൈനും OpenVPN ക്ലയന്റ് സർട്ടിഫിക്കറ്റും വെവ്വേറെ ക്രെഡൻഷ്യൽ വസ്തുക്കളാണ്, വ്യത്യസ്ത ഇഷ്യൂവർമാർ, വ്യത്യസ്ത എൻകോഡിംഗുകൾ, വ്യത്യസ്ത റദ്ദാക്കൽ പാതകൾ. ഈ പരിശോധനകൾ ക്രമത്തിൽ ചെയ്താൽ, പരിവർത്തനം ഒട്ടും സഹായിക്കുമോ എന്ന് ഒരു മിനിറ്റിൽ അറിയാം.

യഥാർത്ഥത്തിൽ ഏത് വസ്തുവാണ് നിങ്ങളുടെ കൈവശം?

ആളുകൾ കീ എന്ന് വിളിക്കുന്ന അഞ്ച് കാര്യങ്ങളുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് TLS പ്രൊഫൈൽ ആഗ്രഹിക്കുന്നത്. SSH പൊതു കീ എന്നത് ടൈപ്പ് പ്രിഫിക്സും base64 പേലോഡും ഉള്ള ഒരു വരി വാചകമാണ്. OpenSSH സർട്ടിഫിക്കറ്റ് എന്നത് ആ കീയ്ക്കൊപ്പം ഒരു ഒപ്പ്, principals, ഓപ്ഷനുകൾ ചേർത്തതാണ്, അത് ssh-keygen തന്റേതായ ചെറിയ CA ആയി പ്രവർത്തിച്ച് നിർമ്മിക്കുന്നു. X.509 സർട്ടിഫിക്കറ്റ് തികച്ചും വ്യത്യസ്തമായ ഘടനയാണ്: വിഷയം, സാധുതാ കാലയളവ്, വിപുലീകരണങ്ങൾ, സർട്ടിഫിക്കറ്റ് അതോറിറ്റിയുടെ ഒപ്പ് എന്നിവ വഹിക്കുന്നു. സ്വകാര്യ കീ രഹസ്യ പകുതിയാണ്, പുറപ്പെടുവിച്ച ബണ്ടിൽ സാധാരണയായി ഒരു ഫയലിൽ സർട്ടിഫിക്കറ്റും അതിന്റെ ശൃംഖലയും സ്വകാര്യ കീയും ചേർന്നതാണ്.

ആദ്യ പരിശോധനയ്ക്ക് ഒരു കമാൻഡ് മതി. openssl ഫയലിലേക്ക് ചൂണ്ടി സർട്ടിഫിക്കറ്റ് ഘടന വിശകലനം ചെയ്യാൻ ആവശ്യപ്പെടുക:

openssl x509 -in client.crt -noout -subject -issuer

അത് unable-to-load അല്ലെങ്കിൽ PEM പിശകോടെ പരാജയപ്പെട്ടാൽ, നിങ്ങൾ ഏത് പേര് നൽകിയാലും ആ ഫയൽ X.509 സർട്ടിഫിക്കറ്റല്ല. പേര് മാറ്റുന്നത് ഉള്ളിലെ ASN.1 വീണ്ടും എഴുതുന്നില്ല, പൊതു കീ വരി PEM ഹെഡർ വാചകത്തിൽ പൊതിയുന്നതും അത് ചെയ്യുന്നില്ല.

പ്രൊഫൈൽ സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നുണ്ടോ?

ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകൾ പല പ്രാമാണീകരണ രീതികളിൽ ഒന്നാണ്, പ്രവർത്തിക്കുന്ന പല TLS പ്രൊഫൈലുകളും ഒരിക്കലും അത് ആവശ്യപ്പെടുന്നില്ല. സെർവറിന് പ്ലഗിൻ, ഉപയോക്തൃനാമവും പാസ്വേഡും, അല്ലെങ്കിൽ ടോക്കൺ ബാക്കെൻഡ് വഴി ഉപയോക്താക്കളെ പ്രാമാണീകരിക്കാം, അതേസമയം ക്ലയന്റ് സെർവറിന്റെ ഐഡന്റിറ്റി പരിശോധിക്കണമെന്ന് ആവശ്യപ്പെടുകയും ചെയ്യാം. പ്രൊഫൈലിൽ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് നിർദ്ദേശം ഇല്ലെങ്കിൽ, ഒരിക്കലും സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടില്ല, ഒരു പരിവർത്തനവും ഗേറ്റ്വേയെ അത് ആവശ്യപ്പെടാൻ നിർബന്ധിക്കില്ല.

പഴയ സ്റ്റാറ്റിക് കീ കോൺഫിഗറേഷനുകൾ മൂന്നാമത്തെ കേസാണ്. അവ TLS ഹാൻഡ്ഷേക്കിന് മുമ്പുള്ളവയാണ്, മുൻകൂട്ടി പങ്കിട്ട രഹസ്യ ഫയൽ പ്രതീക്ഷിക്കുന്നു, അതിനാൽ ആ ഫീൽഡിൽ പൊതു കീ ഒട്ടിക്കുന്നതും പ്രവർത്തിക്കില്ല. ക്രെഡൻഷ്യൽ തെറ്റാണെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ എന്താണ് ആവശ്യപ്പെടുന്നതെന്ന് വായിക്കുക.

വീണ്ടും എൻകോഡിംഗ് എന്ത് ചെയ്യാം, എന്ത് ചെയ്യാൻ പാടില്ല

സ്വകാര്യ കീകൾക്ക് യഥാർത്ഥത്തിൽ നിയമപരമായ ബദൽ കണ്ടെയ്നറുകളുണ്ട്. അതേ RSA അല്ലെങ്കിൽ EC കീ പരമ്പരാഗത PEM ആയി, PKCS#8 ആയി, അല്ലെങ്കിൽ PKCS#12 ബണ്ടിലിനുള്ളിൽ എഴുതാം, ഉപകരണങ്ങൾ അവയ്ക്കിടയിൽ സന്തോഷത്തോടെ പരിവർത്തനം ചെയ്യും. പൊതു കീകൾക്കും സമാനമായ കഥയാണ്: ssh-keygen SSH കീയുടെ RFC 4716 രൂപം പുറപ്പെടുവിക്കാം, OpenSSH സ്വന്തം സർട്ടിഫിക്കറ്റ് ഫോർമാറ്റും മനസ്സിലാക്കുന്നു. അതെല്ലാം പ്രാതിനിധ്യമാണ്, പ്രാതിനിധ്യം വിശ്വാസമല്ല.

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

മിക്ക ശ്രമങ്ങളും നിശബ്ദമായി പരാജയപ്പെടുന്ന ഘട്ടം ഇതാണ്: ഫയൽ ഇപ്പോൾ .crt-ൽ അവസാനിക്കുന്നു, ക്ലയന്റ് അത് പരാതിയില്ലാതെ വായിക്കുന്നു, എന്നിട്ടും ഹാൻഡ്ഷേക്ക് തടസ്സപ്പെടുന്നു, കാരണം എതിർകക്ഷിക്ക് വിശ്വസനീയ ഇഷ്യൂവർ വരെ ശൃംഖല നിർമ്മിക്കാൻ കഴിയില്ല.

സർട്ടിഫിക്കറ്റ് അതോറിറ്റി ചിത്രത്തിൽ എവിടെ വരുന്നു

യഥാർത്ഥ രജിസ്ട്രേഷൻ നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു കീ ജോഡിയിൽ നിന്നും ഓപ്പറേറ്റർ പ്രതീക്ഷിക്കുന്ന വിഷയം വഹിക്കുന്ന സർട്ടിഫിക്കറ്റ് ഒപ്പിടൽ അഭ്യർത്ഥനയിൽ നിന്നും ആരംഭിക്കുന്നു. ഓപ്പറേറ്റർ അവകാശം പരിശോധിച്ച്, CA കീ ഉപയോഗിച്ച് അഭ്യർത്ഥനയിൽ ഒപ്പിട്ട്, പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റ് ക്ലയന്റ് സമർപ്പിക്കേണ്ട ഏതെങ്കിലും ഇടനില ശൃംഖലയോടൊപ്പം തിരികെ നൽകുന്നു. തുടർന്ന് ക്ലയന്റിന് അതിൽ ഒപ്പിട്ട CA സർട്ടിഫിക്കറ്റ് ആവശ്യമാണ്, കാരണം താൻ സംസാരിക്കുന്ന സെർവർ അതേ വിന്യാസത്തിൽ ഉൾപ്പെടുന്നു എന്ന് സ്ഥിരീകരിക്കാൻ അതാണ് അവസരം നൽകുന്നത്.

ആ അവസാന ഫയൽ മറക്കാൻ എളുപ്പവും മാറ്റിസ്ഥാപിക്കാൻ അസാധ്യവുമാണ്. CA-യുടെ ഒപ്പിടൽ കീ തന്നെ ഒരിക്കലും ക്ലയന്റ് കോൺഫിഗറേഷനിൽ ഉൾപ്പെടുന്നില്ല, ഏതെങ്കിലും പ്രാദേശിക പരിവർത്തനം നിങ്ങൾക്ക് ലഭിക്കേണ്ടിയിരുന്ന ശൃംഖല നിർമ്മിക്കുന്നുമില്ല.

SSH കീ വീണ്ടും ഉപയോഗിക്കുന്നതിന്റെ ചെലവ്

ഒരു പരിവർത്തനം യഥാർത്ഥത്തിൽ സ്വീകാര്യമായ എന്തെങ്കിലും നിർമ്മിച്ചു എന്ന് കരുതുക. SSH പ്രവേശനത്തിനും VPN പ്രാമാണീകരണത്തിനും ഒരേ കീ ജോഡി വീണ്ടും ഉപയോഗിക്കുന്നത് ഇപ്പോഴും രണ്ട് സ്വതന്ത്ര സുരക്ഷാ തീരുമാനങ്ങളെ ബന്ധിപ്പിക്കുന്നു. authorized_keys-ൽ നിന്ന് ഒരു വരി നീക്കുന്നത് SSH ലോഗിനുകൾ നിർത്തുന്നു, അതേ പൊതു കീയ്ക്കായി VPN CA ഇതിനകം പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റിനോട് ഒന്നും ചെയ്യുന്നുമില്ല. VPN വശം അതിന്റേതായ സംവിധാനത്തിലൂടെ റദ്ദാക്കുന്നു, അതായത് സർട്ടിഫിക്കറ്റ് റദ്ദാക്കൽ പട്ടിക അല്ലെങ്കിൽ ഓപ്പറേറ്ററുടെ രജിസ്ട്രേഷൻ രേഖ.

അതിനാൽ ചെക്ക്ലിസ്റ്റ് ഏതെങ്കിലും തന്ത്രത്തിലല്ല, നിർത്തൽ വ്യവസ്ഥയിൽ അവസാനിക്കുന്നു. openssl ഫയൽ സർട്ടിഫിക്കറ്റായി വിശകലനം ചെയ്യുന്നില്ലെങ്കിൽ, പരിവർത്തനം നിർത്തി നിങ്ങളുടെ കൈവശം എന്താണെന്ന് വിവരിക്കുക: SSH കീ, SSH സർട്ടിഫിക്കറ്റ്, X.509 സർട്ടിഫിക്കറ്റ്, സ്വകാര്യ കീ അല്ലെങ്കിൽ ബണ്ടിൽ. പ്രൊഫൈൽ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നില്ലെങ്കിൽ, നിർത്തി സെർവർ ഏത് പ്രാമാണീകരണ രീതി പ്രതീക്ഷിക്കുന്നു എന്ന് ചോദിക്കുക. രണ്ട് ഉത്തരങ്ങളും X.509-ലേക്ക് ചൂണ്ടുമ്പോൾ മാത്രമാണ് രജിസ്ട്രേഷൻ അടുത്ത ഘട്ടമാകുന്നത്, ആദ്യ വാക്യത്തിൽ ശരിയായ നാമം ഉണ്ടെങ്കിൽ ആ സംഭാഷണം വളരെ വേഗത്തിൽ നടക്കും.