CSR മാത്രം രജിസ്ട്രേഷൻ അല്ല: VPN CA എന്തു പരിശോധിക്കണം
ഒപ്പിടൽ അഭ്യർത്ഥന കീ കൈവശം ഉണ്ടെന്ന് മാത്രം തെളിയിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമല്ല. CA VPN ആക്സസ് നൽകുന്നതിന് മുമ്പ് രജിസ്ട്രേഷൻ മോഡലുകളെ അവ എന്തു ബന്ധിപ്പിക്കുന്നു എന്നതിന്റെ അടിസ്ഥാനത്തിൽ താരതമ്യം ചെയ്യുക.
ഒരു സർട്ടിഫിക്കറ്റ് ഒപ്പിടൽ അഭ്യർത്ഥനയിൽ പൊതു കീയും ആവശ്യപ്പെട്ട subject-ഉം ഉണ്ട്, അവ യോജിക്കുന്ന സ്വകാര്യ കീ ഉപയോഗിച്ച് ഒപ്പിട്ടിരിക്കുന്നു. ആ ഒപ്പ് അഭ്യർത്ഥകന് കീ ഉണ്ടെന്ന് തെളിയിക്കുന്നു. ആവശ്യപ്പെട്ട പേരിനോ ഉപകരണത്തിനോ VPN റോളിനോ അഭ്യർത്ഥകന് അവകാശമുണ്ടെന്ന് അത് തെളിയിക്കുന്നില്ല, അത് തെളിയിക്കുന്നതായി കണക്കാക്കുന്നതാണ് ഹെൽപ്പ് ഡെസ്ക് ടിക്കറ്റ് ആക്സസ് അനുവാദമായി മാറുന്ന വഴി.
രണ്ട് രജിസ്ട്രേഷൻ മോഡലുകളെ അവ ഏത് പ്രോട്ടോക്കോൾ സംസാരിക്കുന്നു എന്നതിലല്ല, എന്തു ബന്ധിപ്പിക്കുന്നു എന്നതിൽ താരതമ്യം ചെയ്യുന്നത് ഉചിതമാണ്.
അഭ്യർത്ഥന ഒരു പേര് അവകാശപ്പെടുന്നു, തെളിയിക്കുന്നില്ല
അഭ്യർത്ഥനയിൽ യഥാർത്ഥത്തിൽ എന്തുണ്ടെന്ന് നോക്കി വായിക്കുക: പൊതു കീ, അഭ്യർത്ഥകൻ തിരഞ്ഞെടുത്ത subject, രണ്ടിനും മേലുള്ള സ്വയം ഒപ്പ്. ആ ഘടനയിൽ നിങ്ങളുടെ ഇൻവെന്ററിയെയോ അക്കൗണ്ട് ഡയറക്ടറിയെയോ അനുമതി പ്രവാഹത്തെയോ പരാമർശിക്കുന്ന ഒന്നുമില്ല. cn=finance-laptop പോലുള്ള subject ആരോ ടൈപ്പ് ചെയ്ത ഒരു സ്ട്രിംഗാണ്. ഇഷ്യൂ ചെയ്യുന്ന പ്രക്രിയ ആ സ്ട്രിംഗ് വിശ്വസിക്കുന്ന ഒരു റെക്കോർഡുമായി പരിശോധിക്കുന്നതുവരെ, സർട്ടിഫിക്കറ്റ് ഒപ്പ് ചേർത്ത ഒരു അവകാശവാദമാണ്. ആ വ്യത്യാസമാണ് രജിസ്ട്രേഷൻ പ്രക്രിയ ഉണ്ടാകാനുള്ള മുഴുവൻ കാരണം.
അതിന്റെ ഫലം പ്രവർത്തനപരമായി പ്രധാനമാണ്. ഒരു സർട്ടിഫിക്കറ്റ് അതോറിറ്റിക്ക് സർട്ടിഫിക്കറ്റ് ഇഷ്യൂ ചെയ്യാൻ ഒരിക്കലും ക്ലയന്റിന്റെ സ്വകാര്യ കീ ആവശ്യമില്ല, അത് ആവശ്യപ്പെടുന്ന പ്രവാഹം ഒപ്പിടലും കീ സൂക്ഷിപ്പും കൂട്ടിക്കുഴച്ചിരിക്കുന്നു. ജനറേഷൻ എൻഡ്പോയിന്റിൽ നിർത്തി പൊതു പകുതി മാത്രം അയയ്ക്കുക.
മോഡലുകളെ അവ എന്തു ബന്ധിപ്പിക്കുന്നു എന്നതിൽ താരതമ്യം ചെയ്യുക
കൈകൊണ്ട് ഒപ്പിടൽ ഓപ്പറേറ്റർ പരിശോധിക്കാൻ ഓർക്കുന്നതിനെ ബന്ധിപ്പിക്കുന്നു. ഓട്ടോമേറ്റഡ് രജിസ്ട്രേഷൻ സേവനം പ്രാമാണീകരിച്ച അഭ്യർത്ഥനയെ സേവനത്തിന് നടപ്പാക്കാനാകുന്ന ഒരു തീരുമാനവുമായി ബന്ധിപ്പിക്കുന്നു, കൂടാതെ RFC 7030 സർട്ടിഫിക്കറ്റ് തിരികെ നൽകുന്നതിന് മുമ്പ് ക്ലയന്റ് പ്രാമാണീകരിക്കുന്ന അത്തരമൊരു രൂപകൽപ്പന വിവരിക്കുന്നു. ഓഡിറ്റിനെ അതിജീവിക്കുന്ന വ്യത്യാസം ഓട്ടോമേഷനല്ല; ഐഡന്റിറ്റി പരിശോധന ഇഷ്യു ചെയ്യുന്ന പാതയ്ക്കുള്ളിലാണോ അതിനൊപ്പമാണോ നടക്കുന്നത് എന്നതാണ്.
രണ്ട് മോഡലുകൾക്കും ഇപ്പോഴും അതേ മൂന്ന് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകണം. ആരാണ് ചോദിക്കുന്നത്, ഏത് ഉപകരണത്തിലോ റോളിലോ, എത്ര കാലത്തേക്ക്. ഉത്തരങ്ങൾ രേഖപ്പെടുത്തുന്ന ടിക്കറ്റ് സംവിധാനം യഥാർത്ഥ ജോലി ചെയ്യുന്നു; ആരോ ഒരു പൊതു പേരിലേക്ക് നോക്കിനിൽക്കുന്ന ക്യൂ ചെയ്യുന്നില്ല, പിന്നീട് സർട്ടിഫിക്കറ്റ് എത്ര ശ്രദ്ധയോടെ ഫോർമാറ്റ് ചെയ്താലും.
നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന രജിസ്ട്രേഷനുകളുടെ എണ്ണവും ഉപകരണങ്ങളുടെ മാറ്റവും അനുസരിച്ച് മോഡൽ തിരഞ്ഞെടുക്കുക. പ്രതിവർഷം കുറച്ച് സർവറുകൾക്ക് രേഖാമൂലമുള്ള ചെക്കലിസ്റ്റോടെ കൈകൊണ്ടുള്ള അവലോകനം താങ്ങാനാകും. ലാപ്ടോപ്പുകളുടെ കൂട്ടത്തിന് താങ്ങാനാകില്ല.
ആദ്യ ഇഷ്യൂ മുതൽ ജീവിതചക്രം രേഖപ്പെടുത്തുക
ഇഷ്യൂ ചെയ്യുന്ന നിമിഷത്തിൽ തന്നെ സർട്ടിഫിക്കറ്റ് ഐഡന്റിഫയർ, ഉടമ, ഉദ്ദേശിച്ച ഉപയോഗം, കാലാവധി, നീക്കം ചെയ്യാനുള്ള വഴി എന്നിവ സംഭരിക്കുക, ആദ്യ സംഭവത്തിന്റെ സമയത്തല്ല. ഉദ്ദേശിച്ച ഉപയോഗം വിപുലീകൃത കീ ഉപയോഗത്തിലൂടെ സർട്ടിഫിക്കറ്റിനുള്ളിൽ തന്നെ ഉണ്ടായിരിക്കണം, റെക്കോർഡ് അതുമായി യോജിക്കണം. ക്ലയന്റ് പ്രാമാണീകരണത്തിനായി നിർമ്മിച്ച സർട്ടിഫിക്കറ്റ് സർവറിനുള്ളതിൽ നിന്ന് വേർതിരിച്ചറിയാനാകാത്തതാകരുത്.
പത്താമത്തെ പ്രൊഫൈൽ ഇഷ്യൂ ചെയ്യുന്നതിന് മുമ്പ് പുതുക്കലും നഷ്ടപ്പെട്ട ഉപകരണം റദ്ദാക്കലും ആസൂത്രണം ചെയ്യുക. ഒരു വിഭാഗത്തിലുടനീളം പങ്കിടുന്ന സർട്ടിഫിക്കറ്റ് ലക്ഷ്യമിട്ട നീക്കം ചെയ്യലിനെ തടസ്സമാക്കി മാറ്റുന്നു, ആ തീരുമാനം ഇപ്പോൾ പുനഃപരിശോധിക്കുന്നത് വെള്ളിയാഴ്ചയിലെ സംഭവത്തിനിടയിലുള്ളതിനേക്കാൾ വളരെ വിലകുറഞ്ഞതാണ്.
ഇഷ്യൂ ചെയ്ത സർട്ടിഫിക്കറ്റ്, തുടർന്ന് ആക്സസ് പരിശോധിക്കുക
രജിസ്ട്രേഷന് ശേഷം എന്താണ് ഇഷ്യൂ ചെയ്തതെന്ന് പരിശോധിച്ച്, അത് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന അതോറിറ്റിയിലേക്ക് ചങ്ങലയായി ബന്ധപ്പെടുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക. രണ്ട് കമാൻഡുകൾ സാധാരണ തെറ്റുകൾ ഉൾക്കൊള്ളുന്നു: തെറ്റായ ഉപയോഗത്തിലുള്ള സർട്ടിഫിക്കറ്റ്, ക്ലയന്റ് വാലിഡേഷൻ അവഗണിക്കാൻ കോൺഫിഗർ ചെയ്തിരിക്കുന്നതുകൊണ്ട് മാത്രം പ്രവർത്തിക്കുന്ന ചങ്ങല.
openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt
തുടർന്ന് ആർട്ടിഫാക്റ്റല്ല, ആക്സസ് പരിശോധിക്കുക. സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി സ്ഥാപിക്കുന്നു, ആ ഐഡന്റിറ്റിക്ക് ഏത് സേവനങ്ങളിൽ എത്താമെന്ന് ഇപ്പോഴും നയമാണ് തീരുമാനിക്കുന്നത്. രണ്ടും പരിശോധിക്കുക, കാരണം ശരിയായ ആർട്ടിഫാക്റ്റും വളരെ വിശാലമായ നയത്തോടൊപ്പം അവലോകനത്തിൽ പരാജയപ്പെടും. ക്ലയന്റ് പ്രാമാണീകരിച്ച് ഉദ്ദേശിച്ച റൂട്ടുകളോ വിഭവങ്ങളോ മാത്രം ലഭിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക. നിങ്ങൾ നിരീക്ഷിച്ചത് രേഖപ്പെടുത്തുക, പ്രൊഫൈൽ ചെയ്യേണ്ടിയിരുന്നതല്ല.
തെറ്റായ കാരണത്താൽ പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ, ഉദാഹരണത്തിന് യോജിക്കുന്ന പൊതു പേരും ഐഡന്റിറ്റി പരിശോധനയുമില്ലാത്തത്, നിങ്ങൾ ഉണ്ടെന്ന് കരുതിയ നിയന്ത്രണം നീക്കിയതിന് ശേഷവും പ്രവർത്തിച്ചുകൊണ്ടിരിക്കും.