സർട്ടിഫിക്കറ്റ് റദ്ദാക്കൽ പരാജയപ്പെടുന്നു: ഏത് ഹോസ്റ്റ് എന്തിലേക്ക് എത്തുന്നില്ല

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

വീണ്ടെടുക്കൽ പാത സാധൂകരണക്കാരന്റേതാണ്

സാധൂകരണക്കാരനെ തിരിച്ചറിഞ്ഞുകൊണ്ട് തുടങ്ങുക. ലാപ്ടോപ്പ് ഗേറ്റ്‌വേയുടെ സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുമ്പോൾ വീണ്ടെടുക്കൽ ലാപ്ടോപ്പാണ് ചെയ്യുന്നത്; ഗേറ്റ്‌വേ ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുമ്പോൾ അത് ഗേറ്റ്‌വേയാണ് ചെയ്യുന്നത്. പിന്നണിയിലുള്ള ഒരു ആധികാരികതാ സേവനത്തിന് സ്വന്തം നെറ്റ്‌വർക്ക് സ്ഥാനത്തോടെ മൂന്നാമതൊരു സാധൂകരണക്കാരനെ ചേർക്കാം. ഓരോന്നിനും വ്യത്യസ്തമായ ഇന്റർനെറ്റ് മാർഗവും വ്യത്യസ്ത പ്രോക്സി ക്രമീകരണവുമുണ്ട്. അഡ്മിനിസ്ട്രേറ്ററുടെ വർക്ക്സ്റ്റേഷനിൽ ശേഖരിച്ച തെളിവുകൾ DMZ-നുള്ളിലെ സെർവറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് സർട്ടിഫിക്കറ്റ്, സാധൂകരണക്കാരൻ, ശ്രമത്തിന്റെ സമയം, കൃത്യമായ സ്ഥിതി കോഡ് എന്നിവ എഴുതിവയ്ക്കുക.

സർട്ടിഫിക്കറ്റിൽ നിന്ന് പ്രസിദ്ധീകരണ പോയിന്റ് വായിക്കുക

സർട്ടിഫിക്കറ്റ് അതിന്റെ അവസ്ഥ എവിടെയാണെന്ന് പറയുന്നു. CA വിലാസം ഊഹിക്കുന്നതിന് പകരം ആ ഫീൽഡുകൾ വായിക്കുക.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

ആദ്യത്തെ എക്സ്റ്റൻഷൻ CRL വിതരണ പോയിന്റുകൾ ലിസ്റ്റ് ചെയ്യുന്നു, രണ്ടാമത്തേത് അധികാര വിവരങ്ങളിലേക്കുള്ള പ്രവേശന രീതികൾ ലിസ്റ്റ് ചെയ്യുന്നു, അവയിൽ OCSP അവസ്ഥയും ഇഷ്യൂവർ സർട്ടിഫിക്കറ്റിന്റെ വീണ്ടെടുക്കലും ഉൾപ്പെടാം. ഇവ വ്യത്യസ്ത സംവിധാനങ്ങളാണ്, OCSP പ്രതികരിക്കുന്നയാൾ CRL ഫയലല്ല. പ്രസിദ്ധീകരണ ഹോസ്റ്റ് പലപ്പോഴും CA യന്ത്രമല്ല, സാധാരണ വെബ് സെർവറാണ്, കാരണം ഓഫ്‌ലൈൻ ഇഷ്യൂവറിന് മറ്റൊരു സെർവർ വിതരണം ചെയ്യുന്ന CRL-ൽ ഒപ്പിടാനാകും. അതിനാൽ CA-യിലേക്കുള്ള പ്രവേശനം എന്ന് വിവരിക്കുന്ന ഫയർവാൾ നിയമം നടപ്പിലാക്കാനോ അവലോകനം ചെയ്യാനോ വളരെ അവ്യക്തമാണ്.

സാധൂകരണം നടത്തുന്ന ഉപകരണത്തിൽ നിന്ന് തന്നെ വീണ്ടെടുക്കൽ പരിശോധിക്കുക

യഥാർഥത്തിൽ സാധൂകരണം നടത്തുന്ന പരിതസ്ഥിതിയിൽ, അംഗീകൃത സർട്ടിഫിക്കറ്റ് മെറ്റീരിയലോടെയും സ്വകാര്യ കീകളില്ലാതെയും വീണ്ടെടുക്കൽ പരിശോധന നടത്തുക.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil പ്രവർത്തിപ്പിക്കുന്നത് ശൃംഖല പരിശോധിച്ച് ഏത് URL വീണ്ടെടുക്കലുകൾ വിജയിച്ചു അല്ലെങ്കിൽ പരാജയപ്പെട്ടു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, അതേസമയം curl വിളി അതേ ഹോസ്റ്റിൽ നിന്ന് ഒരു പ്രസിദ്ധീകരണ വിലാസം മാത്രം പരിശോധിച്ച് സ്ഥിതി കോഡ് മാത്രം തിരികെ നൽകുന്നു. എത്താൻ കഴിയുന്ന വിലാസത്തിൽ നിന്നുള്ള പരാജയപ്പെട്ട വീണ്ടെടുക്കൽ ഉള്ളടക്കമോ ഒപ്പോ ഉള്ള പ്രശ്നങ്ങളിലേക്ക് വിരൽ ചൂണ്ടുന്നു; കണക്ഷൻ പിശക് റൂട്ടിംഗ്, DNS അല്ലെങ്കിൽ പ്രോക്സിയിലേക്ക്. രണ്ട് ഫലങ്ങളും സൂക്ഷിക്കുക, കാരണം ഒരു വിജയകരമായ വീണ്ടെടുക്കൽ മുഴുവൻ ശൃംഖലയും ഉപയോഗയോഗ്യമാണെന്ന് തെളിയിക്കുന്നില്ല. ഉദാഹരണത്തിലെ ഹോസ്റ്റും പാതയും സർട്ടിഫിക്കറ്റിൽ കണ്ടെത്തിയ വിതരണ പോയിന്റിലേക്ക് മാറ്റുക.

കാണാത്ത ഡാറ്റയെ റദ്ദാക്കൽ അവസ്ഥയിൽ നിന്ന് വേർതിരിക്കുക

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

തിരുത്തലിന് ശേഷം പുതിയ ആധികാരികതാ പരിശോധന നിർബന്ധമാക്കി ഉദ്ദേശിച്ച സ്ഥിതി വീണ്ടെടുക്കൽ വിജയിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. നിയന്ത്രിത പരീക്ഷണ ഐഡന്റിറ്റി ഉള്ളിടത്ത്, അത് ഇപ്പോഴും നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം പരിശോധന നീക്കുന്ന ലഭ്യത തിരുത്തലല്ല.