റദ്ദാക്കിയ VPN സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും കണക്റ്റ് ചെയ്യുന്നുണ്ടോ? CRL പ്രയോഗം പരിശോധിക്കുക

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

താഴെയുള്ള അഞ്ച് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യത്തെ പരാജയത്തിൽ നിർത്തുക, കാരണം ഓരോ തുടർന്നുള്ള പരിശോധനയും മുൻപുള്ളവ ശരിയെന്ന് കരുതുന്നു.

ഏത് ഘടകമാണ് സ്വീകാര്യതാ തീരുമാനം എടുക്കുന്നതെന്ന് പരിശോധിക്കുക

ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുന്ന പ്രക്രിയയെ പേരിടുക, കാരണം ആ പ്രക്രിയയ്ക്ക് മാത്രമേ ഒരു ലിസ്റ്റ് പ്രയോഗിക്കാനാകൂ. OpenVPN സെർവറിൽ അത് ഡീമൺ തന്നെയാണ്, crl-verify ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്തത്. ocserv-ൽ അത് ocserv.conf-ലെ crl വരിയാണ്. strongSwan-ൽ ഇൻപുട്ടുകൾ ലോഡ് ചെയ്ത CRL-കളും strictcrlpolicy ഉം ചേർന്നതാണ്. VPN-ന്റെ മുന്നിൽ TLS അവസാനിപ്പിക്കുന്ന പ്രോക്സിയോ ഉപകരണമോ യഥാർത്ഥ പരിശോധകനുമാകാം, അങ്ങനെയെങ്കിൽ അതിന് പിന്നിലെ ഡീമൺ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഒരിക്കലും കാണുന്നില്ല.

WireGuard മറ്റൊരു വിഭാഗത്തിലാണ്. അതിന് സർട്ടിഫിക്കറ്റുകളുമില്ല, റദ്ദാക്കൽ ലിസ്റ്റുമില്ല; കോൺഫിഗറേഷനിലെ അതിന്റെ പൊതു കീ വഴി പീയർ സ്വീകരിക്കപ്പെടുന്നു, അതിനാൽ പ്രവേശനം അവസാനിപ്പിക്കുക എന്നത് ആ കീ നീക്കം ചെയ്യുകയാണ്. WireGuard മാത്രമുള്ള വിന്യാസത്തിൽ CRL തിരയുകയാണെങ്കിൽ, ആ സംവിധാനം അവിടെയില്ല.

ക്ലയന്റ് ഭാഗത്തെ കെണിയിൽ നിന്നും ജാഗ്രത പാലിക്കുക. സെർവറിന്റെ സർട്ടിഫിക്കറ്റ് ഇഷ്ടപ്പെടാത്തതിനാൽ കണക്റ്റ് ചെയ്യാൻ വിസമ്മതിക്കുന്ന ക്ലയന്റ് സെർവറിന്റെ ചെയിനാണ് പ്രയോഗിക്കുന്നത്, സ്വന്തം ക്രെഡൻഷ്യലുകൾ റദ്ദാക്കുന്നില്ല. ഉപയോക്തൃ സർട്ടിഫിക്കറ്റ് ആ സർട്ടിഫിക്കറ്റ് പരിശോധിക്കപ്പെടുന്നിടത്ത് മാത്രമേ റദ്ദാക്കപ്പെടൂ, അത് ഏതാണ്ട് എപ്പോഴും സെർവർ ഭാഗമാണ്.

ഏത് ഇഷ്യൂവർക്കായി ലിസ്റ്റ് സൈൻ ചെയ്തുവെന്ന് പരിശോധിക്കുക

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

ഡീമണെ തൊടുന്നതിന് മുമ്പ് ജോടി ഉറപ്പാക്കുക. സർട്ടിഫിക്കറ്റിലെ ഇഷ്യൂവർ ലിസ്റ്റിന്റെ subject-മായി പൊരുത്തപ്പെടണം:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

രണ്ടും ഒരേ CA-യിൽ നിന്ന് വരുമ്പോൾ, സർട്ടിഫിക്കറ്റിനായി അച്ചടിച്ച ക്രമ നമ്പറാണ് ലിസ്റ്റിൽ വരേണ്ട മൂല്യം. അവ പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, നിങ്ങളുടെ പക്കൽ തെറ്റായ CRL അല്ലെങ്കിൽ അതിന്റെ തെറ്റായ പകർപ്പ് ഉണ്ട്.

സാധുത അതേ പരിശോധനയുടേതാണ്. ഭൂതകാലത്തിലെ nextUpdate ലിസ്റ്റിനെ പഴയതാക്കുന്നു, അടച്ച രീതിയിൽ പരാജയപ്പെടുന്ന പരിശോധകൻ അപ്പോൾ റദ്ദാക്കപ്പെട്ടതിനെ മാത്രമല്ല, ഓരോ ക്ലയന്റിനെയും നിരസിക്കും.

ക്രമ നമ്പർ ഡീമൺ ലോഡ് ചെയ്ത പകർപ്പിലുണ്ടോ എന്ന് പരിശോധിക്കുക

റദ്ദാക്കൽ CA ഡാറ്റാബേസിൽ ഒരു എൻട്രി എഴുതുന്നു, പുനർനിർമ്മാണം പുതിയ ഫയൽ എഴുതുന്നു. രണ്ടിൽ ഒന്നും തുടക്കത്തിൽ പഴയ പകർപ്പ് ലോഡ് ചെയ്ത പ്രവർത്തിക്കുന്ന ഡീമണിൽ എത്തുന്നില്ല. ലിസ്റ്റ് ഡംപ് ചെയ്ത് ക്രമ നമ്പർ തിരയുക:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

തുടർന്ന് നിങ്ങളുടെ നടപ്പാക്കൽ ഫയൽ എങ്ങനെ എടുക്കുന്നുവെന്ന് പരിശോധിക്കുക. OpenVPN crl-verify-ന് നൽകിയ പാത തുടക്കത്തിൽ ഒരിക്കൽ വായിക്കുന്നു, അതിനാൽ പുതിയ ലിസ്റ്റിന് പുനരാരംഭമോ പുനരാരംഭ സിഗ്നലോ ആവശ്യമാണ്; അതേ ഓപ്ഷൻ ഏതെങ്കിലും ഡയറക്ടറിയിലേക്കാണെങ്കിൽ ഓരോ കണക്ഷനിലും വീണ്ടും വായിക്കുന്നു, അതുകൊണ്ടാണ് ഡയറക്ടറി മോഡ് ഉള്ളത്. strongSwan അതിന്റെ ക്രെഡൻഷ്യലുകൾ വീണ്ടും ലോഡ് ചെയ്യണം, ഉദാഹരണത്തിന് swanctl --load-creds ഉപയോഗിച്ച്. ഫയൽ ഡിസ്കിൽ ശരിയായിരിക്കുകയും പരിശോധകൻ അത് ഉപയോഗിക്കുകയും ചെയ്യുന്നത് രണ്ട് വ്യത്യസ്ത വസ്തുതകളാണ്.

കാണാത്തതോ കാലഹരണപ്പെട്ടതോ ആയ ലിസ്റ്റിന്റെ നയം പരിശോധിക്കുക

ഇത് പല വിന്യാസങ്ങളും ഒരിക്കലും വ്യക്തമായി എടുക്കാത്ത തീരുമാനമാണ്, റദ്ദാക്കൽ നിങ്ങളെ സംരക്ഷിക്കുന്നുണ്ടോ അതോ എല്ലാവരെയും പുറത്ത് പൂട്ടുന്നുണ്ടോ എന്ന് അത് തീരുമാനിക്കുന്നു. Fail-closed എന്നാൽ ഉപയോഗയോഗ്യമായ റദ്ദാക്കൽ വിവരമില്ലാതെ നിരസിക്കൽ സംഭവിക്കുന്നു; fail-open എന്നാൽ പരിശോധകൻ അതില്ലാതെ തുടരുന്നു. strongSwan തിരഞ്ഞെടുപ്പ് strictcrlpolicy ആയി അവതരിപ്പിക്കുന്നു. OpenVPN crl-verify ഉപയോഗിച്ച് വായിക്കാനോ പാഴ്സ് ചെയ്യാനോ കഴിയാത്ത ഫയലിൽ ആരംഭിക്കാൻ വിസമ്മതിക്കുന്നു, കാലഹരണപ്പെട്ട ലിസ്റ്റ് നിശ്ശബ്ദ സ്വീകാര്യതയ്ക്ക് പകരം കാലഹരണപ്പെട്ട CRL സംബന്ധിച്ച TLS പരിശോധന പിശകായി പ്രത്യക്ഷപ്പെടുന്നു.

നിങ്ങൾ ഏത് ദിശ തിരഞ്ഞെടുത്താലും, ഓട്ടോമേഷൻ തിരഞ്ഞെടുപ്പിനേക്കാൾ പ്രധാനമാണ്: CRL nextUpdate-ന് മുമ്പ് പുനർനിർമ്മിക്കുന്ന ജോലിയും, വിന്യസിച്ച പകർപ്പ് പഴയതാകുമ്പോഴുള്ള മുന്നറിയിപ്പും, രണ്ട് നയങ്ങളെയും സംഭവമാകുന്നതിൽ നിന്ന് തടയുന്നു. OCSP ഉപയോഗിച്ചുള്ള ഓൺലൈൻ പരിശോധന പുതുമ പ്രതികരിക്കുന്നയാളിലേക്ക് നീക്കുന്നു, പക്ഷേ അതേ നിയമം ബാധകമാണ്, കാരണം മറുപടി പരിശോധിക്കാൻ കോൺഫിഗർ ചെയ്യാത്ത പരിശോധകൻ ഒന്നും മാറ്റുന്നില്ല.

സജീവ സെഷനും, തുടർന്ന് കീയുടെ പകർപ്പുകളും പരിശോധിക്കുക

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

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

ഇത് പൂർത്തിയായി പറയുന്നതിന് മുമ്പ്: പരിശോധിക്കുന്ന ഘടകം തിരിച്ചറിഞ്ഞു, ലിസ്റ്റിന്റെ ഇഷ്യൂവർ ഇലയുടെ ഇഷ്യൂവറുമായി പൊരുത്തപ്പെടുന്നു, റദ്ദാക്കിയ ക്രമ നമ്പർ ഡീമൺ യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത പകർപ്പിലുണ്ട്, കാണാത്തതോ കാലഹരണപ്പെട്ടതോ ആയ ലിസ്റ്റുകളുടെ നയം ബോധപൂർവമാണ്, നിരീക്ഷിക്കപ്പെടുന്നു, സജീവ സെഷൻ കാത്തിരിക്കുന്നതിന് പകരം അവസാനിപ്പിച്ചു. ഇവയ്ക്കെല്ലാം പിന്നിലെ ഫോർമാറ്റുകൾ RFC 5280-ൽ വ്യക്തമാക്കിയിരിക്കുന്നു.