ഒരു പൊതുനാമം, രണ്ട് സർട്ടിഫിക്കറ്റുകൾ: അനുവദനീയ പട്ടികയോ റദ്ദാക്കലോ?

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

സർവർ ഉപയോഗിക്കുന്ന നാമകരണ നയത്തിൽ നിന്ന് തുടങ്ങുക

രണ്ട് നിയന്ത്രണങ്ങൾ കൂടിക്കലരുന്നു: ഒരു ക്ലയന്റ് താൻ ആരാണെന്ന് അവകാശപ്പെടുന്നതിനാൽ അതിനെ സ്വീകരിക്കുന്നതും, ഒരു നിർദ്ദിഷ്ട സർട്ടിഫിക്കറ്റ് സേവനത്തിൽ നിന്ന് നീക്കം ചെയ്യുന്നതും. ആദ്യത്തേത് നാമ പരിശോധനയാണ്, രണ്ടാമത്തേത് റദ്ദാക്കൽ പരിശോധനയാണ്. അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ഒരു വിന്യാസത്തിൽ ഒന്ന് മറ്റൊന്നില്ലാതെയും ആകാം.

സർവർ കോൺഫിഗറേഷൻ വായിച്ച് ഏത് ഐഡന്റിറ്റി ഉറവിടമാണ് പ്രവർത്തനത്തിലുള്ളതെന്ന് ശ്രദ്ധിക്കുക. username-as-common-name എന്നത് പ്രാമാണീകരിച്ച ഉപയോക്തൃനാമത്തെ ക്ലയന്റ്-നിർദ്ദിഷ്ട തിരച്ചിലുകൾക്കുള്ള ഫലപ്രദമായ നാമമാക്കുന്നു. അതില്ലാതെ, സർട്ടിഫിക്കറ്റിലെ വിഷയ പൊതുനാമം ഉപയോഗിക്കുന്നു. ഉത്തരം എന്തുതന്നെയായാലും, ഏതെങ്കിലും അനുവദനീയ പട്ടിക തൊടുന്നതിന് മുൻപ് അത് എഴുതിവയ്ക്കുക.

രണ്ട് പാതകളും ഒരേ സർട്ടിഫിക്കറ്റിന് വ്യത്യസ്ത അനുവദനീയ നാമങ്ങളുടെ കൂട്ടം നൽകുന്നു. ഇവിടെ ഊഹിക്കുന്നത് തെറ്റായ ഫയൽ തിരുത്തിയതും നിയന്ത്രണം പ്രവർത്തിക്കുന്നില്ലെന്ന് തീരുമാനിച്ചതുമാണ്.

ഒരു ക്ലയന്റിനെ യഥാർത്ഥത്തിൽ സ്വീകരിക്കുന്നത് എന്തെന്ന് പരിശോധിക്കുക

പൊരുത്തപ്പെടുന്ന ഫയലുള്ള client-config-dir ക്ലയന്റ്-നിർദ്ദിഷ്ട ഓപ്ഷനുകൾ നൽകുന്നു; അത് മാത്രം പ്രവേശന നിയമമല്ല. നാമപ്രകാരം പ്രവേശനത്തിന് ccd-exclusive ആവശ്യമാണ്, അത് പൊരുത്തപ്പെടുന്ന ഫയലില്ലാത്ത ക്ലയന്റുകളെ നിരസിക്കുന്നു. പ്രവർത്തനത്തിലുള്ള ഒരു വിന്യാസത്തിൽ അത് ഓണാക്കിയാൽ ഫയലില്ലാത്ത പേരുള്ള എല്ലാവരുടെയും ബന്ധം വിച്ഛേദിക്കപ്പെടും, അതിനാൽ എന്തും മാറ്റുന്നതിന് മുൻപ് ഫയലുകൾ എണ്ണുക.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

എണ്ണം തന്നെയാണ് പരിശോധന: ഡയറക്ടറി ലിസ്റ്റിംഗ് നിങ്ങൾ ബന്ധിപ്പിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റികളുമായി താരതമ്യപ്പെടുത്തുക.

തുടർന്ന് ഓരോ ഫയൽനാമവും കേസും ഇടവേളകളും ഉൾപ്പെടെ ഫലപ്രദമായ ഐഡന്റിറ്റിയുമായി കൃത്യമായി പൊരുത്തപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. office-laptop എന്നതിനുള്ള ഫയൽ വിഷയം Office-Laptop എന്ന് വായിക്കുന്ന സർട്ടിഫിക്കറ്റിന് ഒന്നും ചെയ്യുന്നില്ല. അവസാനത്തിലുള്ള ഇടവേളകളും സാധാരണ ലിസ്റ്റിംഗിൽ നിന്ന് മറയുന്നു, അങ്ങനെ ഉള്ളതായി തോന്നുന്ന ഫയൽ വായിക്കപ്പെടാതെ തുടരുന്നു.

ഗേറ്റ്വേ ലോഡ് ചെയ്യുന്ന CRL പരിശോധിക്കുക

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

ഫയലിനെ ഒട്ടും വിശ്വസിക്കുന്നതിന് മുൻപ് ക്രമീകരിച്ച പാത, ഇഷ്യൂ തീയതി, അടുത്ത അപ്ഡേറ്റ് ഫീൽഡ് എന്നിവ ഉറപ്പാക്കുക.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

നിലനിർത്താൻ ഉദ്ദേശിക്കുന്ന സർട്ടിഫിക്കറ്റിലെ സീരിയൽ നമ്പറുമായി CRL-ലെ സീരിയൽ നമ്പർ താരതമ്യപ്പെടുത്തുക. ആ താരതമ്യമാണ് മുഴുവൻ പരീക്ഷ, ഒരിക്കൽ കണ്ണുകൊണ്ട് ചെയ്യുന്നത് ആരും വായിക്കാത്ത ഒരു സ്ക്രിപ്റ്റിനെ വിശ്വസിക്കുന്നതിനേക്കാൾ മൂല്യമുള്ളതാണ്. അപ്ഡേറ്റ് ചെയ്ത CRL ഗേറ്റ്വേ ഇതിനകം വായിക്കുന്ന പാതയിലൂടെ വിതരണം ചെയ്യുക. തെറ്റായ ഡയറക്ടറിയിലിരിക്കുന്ന CRL ഒന്നും നടപ്പാക്കുന്നില്ല, ഏതെങ്കിലും ക്ലയന്റ് ലോഗ് അത് പരാമർശിക്കുകയുമില്ല.

മാറ്റിസ്ഥാപിക്കുക, തുടർന്ന് രണ്ട് ഫലങ്ങളും തെളിയിക്കുക

അതേ പൊതുനാമത്തിൽ പകരം നൽകുക, രണ്ട് സീരിയൽ നമ്പറുകളും രേഖപ്പെടുത്തുക, അതിനുശേഷം മാത്രം പഴയത് റദ്ദാക്കുക. ആ ക്രമം മാറ്റം തയ്യാറാക്കുമ്പോൾ പ്രവർത്തിക്കുന്ന ഒരു ഐഡന്റിറ്റി ലഭ്യമായി നിലനിർത്തുന്നു.

ആദ്യം പകരം പരീക്ഷിക്കുക: അത് പ്രാമാണീകരിച്ച് അതിന്റെ പേരിന് അർഹതയുള്ളതെല്ലാം എത്തിച്ചേരണം. തുടർന്ന് പഴയ സർട്ടിഫിക്കറ്റ് പരീക്ഷിച്ച് അത് നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം വിജയകരമായ പകരം റദ്ദാക്കലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. രണ്ടും ഇപ്പോഴും ബന്ധിപ്പിക്കുന്നുവെങ്കിൽ, റദ്ദാക്കൽ ഇൻപുട്ട് വായിക്കപ്പെടുന്നില്ല അല്ലെങ്കിൽ പഴയ സീരിയൽ നമ്പർ ഒരിക്കലും ലിസ്റ്റ് ചെയ്തിട്ടില്ല. ഒന്നും ബന്ധിപ്പിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ ക്രെഡൻഷ്യലല്ല, പ്രവേശന നിയമമാണ് തകർത്തത്.

ഇതിനകം സ്ഥാപിതമായ സെഷനുകൾ വേറെ കാര്യമാണ്, കാരണം ഗേറ്റ്വേ സജീവ കണക്ഷനുകൾ വിച്ഛേദിക്കാൻ ക്രമീകരിച്ചിട്ടില്ലെങ്കിൽ റദ്ദാക്കൽ പുതിയ പ്രാമാണീകരണങ്ങൾക്ക് മാത്രം ബാധകമാണ്. ആർക്കെങ്കിലും വാഗ്ദാനം ചെയ്യുന്നതിന് മുൻപ് തൽക്ഷണ നീക്കം ആവശ്യമാണോ എന്ന് തീരുമാനിക്കുക.

നാമ പരിശോധനയ്ക്ക് ഒരിക്കലും ചെയ്യാനാവാത്തത്

ഈ ഐഡന്റിറ്റിക്ക് ബന്ധിപ്പിക്കാമോ എന്നതിന് അനുവദനീയ പട്ടിക ഉത്തരം നൽകുന്നു. ആ ഐഡന്റിറ്റി ഏത് സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ചുവെന്ന് അതിന് പറയാനാവില്ല, ക്രെഡൻഷ്യൽ സാധുവായി റദ്ദാക്കപ്പെടാതെ തുടരുന്നിടത്തോളം പഴയ ക്രെഡൻഷ്യൽ അത് സ്വീകരിക്കും. ആ വിടവ് ഒരു സംഭവവേളയിൽ പ്രകടമാകുന്നു, പകരം മാസങ്ങൾക്ക് മുൻപ് നൽകിയതും മുൻഗാമി ഇപ്പോഴും പ്രവർത്തിക്കുന്നതുമായ സമയത്ത്.

സർട്ടിഫിക്കറ്റ് തലത്തിലുള്ള നിയന്ത്രണം ആവശ്യമുള്ളിടത്ത്, സർട്ടിഫിക്കറ്റിനെ പേരിടുന്ന ഒരു സംവിധാനം ഉപയോഗിക്കുക: CRL എൻട്രികൾ, അല്ലെങ്കിൽ ഓപ്പറേറ്റർ പരിപാലിക്കുന്ന ഒരു ഫിംഗർപ്രിന്റ് പരിശോധിക്കുന്ന വെരിഫൈ ഹുക്ക്. രണ്ടിനും പരിപാലന ചെലവുണ്ട്, രണ്ടും തങ്ങൾ പരിശോധിക്കുന്ന വസ്തുവിനെക്കുറിച്ച് സത്യസന്ധമാണ്. OpenVPN 2.6 മാനുവൽ പ്രകാരം crl-verify ഉം ക്ലയന്റ്-നിർദ്ദിഷ്ട പ്രവേശനവും വെവ്വേറെ ഓപ്ഷനുകളായി രേഖപ്പെടുത്തിയിരിക്കുന്നു, അതേ കാരണത്താൽ.

ഏത് നിയന്ത്രണം ഏത് ജോലി ചെയ്യുന്നുവെന്ന് എഴുതിവയ്ക്കുക, തുടർന്ന് നെഗറ്റീവ് കേസ് പരീക്ഷിക്കുക. ഒരു കണക്ഷൻ നിരസിക്കുന്നത് ഒരിക്കലും കാണാത്ത റദ്ദാക്കൽ നിങ്ങൾ പ്രവർത്തിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന ഒരു ക്രമീകരണമാണ്.