VPN സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും സാധുവല്ല: മൂന്ന് കാരണങ്ങൾ, ഒരു പരിശോധന ക്രമം
ഇപ്പോഴും സാധുവല്ല എന്നാൽ ഉപകരണത്തിന്റെ ഘടികാരം പിന്നിലാണ്, വിൻഡോ ശരിക്കും പിന്നീട് ആരംഭിക്കുന്നു, അല്ലെങ്കിൽ ഇടനില സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും തുറന്നിട്ടില്ല. അവ ഈ ക്രമത്തിൽ പരിശോധിക്കുക.
നിങ്ങൾ ക്ലയന്റ് തുറന്ന്, മാസങ്ങളായി ഉപയോഗിക്കുന്ന പ്രൊഫൈൽ തിരഞ്ഞെടുക്കുമ്പോൾ, അത് "certificate is not yet valid" എന്ന സന്ദേശത്തോടെ നിലയ്ക്കുന്നു. നിങ്ങളുടെ സൈൻ-ഇന്നിൽ ഒന്നും മാറിയിട്ടില്ല, ട്രസ്റ്റ് സ്റ്റോർ സാധാരണയായി കുഴപ്പമില്ല: ഹാൻഡ്ഷേക്കിൽ അവതരിപ്പിച്ച സർട്ടിഫിക്കറ്റിന് പരിശോധകൻ ഉപയോഗിക്കുന്ന നിമിഷത്തിന് ശേഷം ആരംഭിക്കുന്ന സാധുതാ വിൻഡോയുണ്ട്. മൂന്ന് വ്യത്യസ്ത സാഹചര്യങ്ങൾ അതേ സന്ദേശം ഉണ്ടാക്കുന്നു, അവയ്ക്ക് വ്യത്യസ്ത നടപടികൾ വേണം. താഴെയുള്ള ക്രമം ഘടികാരമോ സർട്ടിഫിക്കറ്റ് ഫയലോ തൊടുന്നതിന് മുൻപ് ഏതാണെന്ന് പറയും.
മൂന്ന് കാരണങ്ങളിൽ ഏതാണ് നിങ്ങൾ കാണുന്നത്
ആദ്യ കാരണം പ്രാദേശികമാണ്: പരിശോധന നടത്തുന്ന ഉപകരണത്തിന്റെ ഘടികാരം സർട്ടിഫിക്കറ്റിന്റെ ആരംഭ തീയതിക്ക് മുൻപാണ്. മരിച്ച CMOS ബാറ്ററിയുള്ള ഹാർഡ്വെയറിലും, പഴയ സ്നാപ്പ്ഷോട്ടിൽ നിന്ന് പുനഃസ്ഥാപിച്ച വെർച്വൽ മെഷീനുകളിലും, സമയം നഷ്ടപ്പെടാൻ മതിയായ സമയം ഓഫ് ആയിരുന്ന ഉപകരണങ്ങളിലും, പുറത്തേക്കുള്ള NTP തടയപ്പെട്ടത് ആരും ശ്രദ്ധിക്കാത്ത നെറ്റ്വർക്കുകളിലും ഇത് കാണാം. സർട്ടിഫിക്കറ്റ് പൂർണ്ണമായി സാധുവായിരിക്കാം, എന്നിട്ടും ഈ രീതിയിൽ പരാജയപ്പെടാം.
രണ്ടാമത്തെ കാരണം ഇഷ്യൂ ചെയ്യുന്നയാളുടേതാണ്, കാരണം സർട്ടിഫിക്കറ്റ് ശരിക്കും ഭാവിയിൽ ആരംഭിക്കുന്നു: നേരത്തെ ഇഷ്യൂ ചെയ്തത്, വ്യക്തമായ ആരംഭ സമയത്തോടെ സൃഷ്ടിച്ചത്, അല്ലെങ്കിൽ ഇപ്പോഴും പ്രവർത്തിച്ചിട്ടില്ലാത്ത ആക്ടിവേഷൻ ഘട്ടത്തിന്റെ ഭാഗമായി ഒപ്പിട്ടത്. മൂന്നാമത്തെ കാരണം ഏറ്റവും സമയം നഷ്ടപ്പെടുത്തുന്നു, കാരണം ലീഫ് നിലവിലുള്ളതാണ്, എന്നാൽ അവതരിപ്പിച്ച ചെയിനിലെ മറ്റൊരു സർട്ടിഫിക്കറ്റ് അല്ല, അതിനാൽ പിശക് നിങ്ങൾ ഒരിക്കലും ഇൻസ്റ്റാൾ ചെയ്യാത്ത വസ്തുവിനെ പേരെടുത്ത് പറയുന്നു.
ഒരു ചോദ്യം അവയെ വേർതിരിക്കുന്നു. പരാജയം ഉപകരണത്തെ അനുഗമിക്കുന്നുണ്ടോ അതോ സേവനത്തെ? ഒരേ നെറ്റ്വർക്കിലെ രണ്ട് മെഷീനുകൾ വ്യത്യസ്തമായി പെരുമാറിയാൽ അത് ഘടികാരങ്ങളെ സൂചിപ്പിക്കുന്നു. എല്ലാ ക്ലയന്റുകളും ഒരേ രീതിയിൽ പരാജയപ്പെട്ടാൽ അത് സർട്ടിഫിക്കറ്റിന്റെ വിൻഡോയെയും അതിന് പിന്നിലെ ചെയിനെയും സൂചിപ്പിക്കുന്നു.
യഥാർത്ഥത്തിൽ അവതരിപ്പിച്ച സർട്ടിഫിക്കറ്റിൽ നിന്ന് വിൻഡോ വായിക്കുക
മുൻ വിന്യാസത്തിൽ നിന്ന് അവശേഷിച്ച PEM ഫയൽ പരിശോധിക്കരുത്; ഇപ്പോൾ അയയ്ക്കുന്ന ചെയിനിനായി സേവനത്തോട് ചോദിക്കുക. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts ചെയിനിലെ ഓരോ സർട്ടിഫിക്കറ്റും പ്രിന്റ് ചെയ്യുന്നു. നിങ്ങൾക്ക് വേണ്ട ബ്ലോക്ക് സേവ് ചെയ്ത് openssl x509 -noout -subject -issuer -dates പ്രവർത്തിപ്പിക്കുക; അവസാനത്തേത് notBefore, notAfter എന്നിവ പ്രിന്റ് ചെയ്യുന്നു, ആ രണ്ട് മൂല്യങ്ങളാണ് തീരുമാനിക്കുന്നത്. Windows-ൽ, കണക്ഷന്റെ സർട്ടിഫിക്കറ്റ് ഡയലോഗും എക്സ്പോർട്ട് ചെയ്ത ഫയലിലെ certutil -dump ഉം അതേ ഫീൽഡുകൾ കാണിക്കുന്നു.
വിൻഡോയുടെ രണ്ട് അറ്റങ്ങളും വായിക്കുക, തുടക്കം മാത്രമല്ല. രണ്ട് മണിക്കൂറിന് ശേഷം തുറക്കുന്ന സർട്ടിഫിക്കറ്റും രണ്ട് മണിക്കൂറിന് ശേഷം അടയ്ക്കുന്നതും വ്യത്യസ്ത സന്ദേശങ്ങളോടെ പരാജയപ്പെടുന്നു, വ്യത്യസ്ത ടീമുകളെ ഉൾപ്പെടുത്തുന്നു. പിശക് ഏത് സർട്ടിഫിക്കറ്റിനെ പേരെടുത്ത് പറയുന്നു എന്നത് ശ്രദ്ധിക്കുക — ലീഫ്, ഇടനില അല്ലെങ്കിൽ റൂട്ട് — കാരണം ക്ലയന്റ് വശത്ത് എന്തെങ്കിലും പരിഹരിക്കാനാകുമോ എന്നത് അത് തീരുമാനിക്കുന്നു.
വിൻഡോയ്ക്കായി കാത്തിരിക്കാതെയും പരീക്ഷിക്കാം. പരിശോധന വ്യക്തമായ സമയം സ്വീകരിക്കുന്നു: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem ആ ടൈംസ്റ്റാമ്പിൽ ചെയിൻ വിലയിരുത്തുന്നു. പരാജയം പുനരാവിഷ്കരിക്കാൻ നിലവിലെ സമയത്തോടെ പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് വിൻഡോ തുറന്നതിന് ശേഷം അതേ ചെയിൻ കടന്നുപോകുന്നുവെന്ന് സ്ഥിരീകരിക്കാൻ സർട്ടിഫിക്കറ്റിന്റെ ആരംഭ സമയത്തോടെ പ്രവർത്തിപ്പിക്കുക. RFC 5280 സാധുതാ ഫീൽഡും അതിന് പുറത്ത് സർട്ടിഫിക്കറ്റ് ഉപയോഗിക്കരുതെന്ന നിയമവും നിർവചിക്കുന്നു, നിങ്ങളുടെ ക്ലയന്റ് ഇപ്പോൾ പ്രയോഗിച്ചത് അതേ നിയമമാണ്.
നിങ്ങളുടെ ഘടികാരമോ അവരുടേതോ
ഉപകരണത്തിന്റെ ഘടികാരം സർട്ടിഫിക്കറ്റിന്റെ UTC ആരംഭവുമായി, നിങ്ങൾ വിശ്വസിക്കുന്ന ഉറവിടത്തിൽ നിന്ന് താരതമ്യം ചെയ്യുക. date -u നിമിഷം നൽകുന്നു, systemd ഹോസ്റ്റിൽ timedatectl status ഘടികാരം സമന്വയിപ്പിച്ചിട്ടുണ്ടോ എന്നും റിപ്പോർട്ട് ചെയ്യുന്നു. Windows-ൽ, w32tm /query /status നിലവിലെ ഉറവിടവും അവസാന വിജയകരമായ സമന്വയവും കാണിക്കുന്നു. ട്രേയിൽ കാണിക്കുന്ന സമയ മേഖല ഒരു ഡിസ്പ്ലേ തിരഞ്ഞെടുപ്പാണ്, തെറ്റായ ഘടികാരമല്ല; പരിശോധകൻ UTC നിമിഷങ്ങൾ താരതമ്യം ചെയ്യുന്നു.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
ഘടികാരം പിന്നിലാണെങ്കിൽ, സർട്ടിഫിക്കറ്റ് വസ്തുവകകൾ മാറ്റുന്നതിന് മുൻപ് വീണ്ടും സമന്വയിപ്പിച്ച് വീണ്ടും പരീക്ഷിക്കുക. കുറച്ച് മിനിറ്റോ മണിക്കൂറോ തെറ്റായ ഉപകരണം തനിക്ക് കണ്ടുമുട്ടുന്ന ഓരോ അടുത്തിടെ ഇഷ്യൂ ചെയ്ത സർട്ടിഫിക്കറ്റും നിരസിക്കുന്നു, ഒരു സേവനത്തെ മാത്രമല്ല, അതിനാൽ ഒറ്റ-സേവന വിശദീകരണം സാധാരണയായി തെറ്റാണ്. ഘടികാരം ശരിയും സമന്വയിപ്പിച്ചതുമാണെങ്കിൽ ഉപകരണത്തെ നോക്കുന്നത് നിർത്തുക: വിൻഡോ ഇഷ്യൂ ചെയ്യുന്നയാളുടേതാണ്, അത് കടന്നുപോകാൻ ഒരു പ്രാദേശിക ക്രമീകരണവും മാറ്റരുത്.
ആ പട്ടികയാണ് മുഴുവൻ തീരുമാനം. സർട്ടിഫിക്കറ്റ് പ്രതീക്ഷിക്കുന്നതിലേക്ക് ഘടികാരം നീക്കുന്നത് പരിഹാരമല്ല, സമയ പരിശോധനകൾ ഓഫ് ചെയ്യുന്നതും പരിഹാരമല്ല, കാരണം രണ്ടും പിശക് ഉണ്ടാക്കിയ അവസ്ഥ മറയ്ക്കുന്നു.
ലീഫ് കുഴപ്പമില്ലാതെ കാണുമ്പോൾ ചെയിൻ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
പുതുക്കിയ ലീഫുകളും മാറ്റിസ്ഥാപിക്കുന്ന ഇടനില സർട്ടിഫിക്കറ്റുകളും സാധാരണയായി ഒരുമിച്ചാണ് അയയ്ക്കുന്നത്, എപ്പോഴും ഒരേ നിമിഷത്തിൽ എത്തുന്നില്ല. സേവനം സ്വന്തം വിൻഡോ പിന്നീട് ആരംഭിക്കുന്ന ഇടനില ഒപ്പിട്ട പുതിയ ലീഫ് അയയ്ക്കാം, അല്ലെങ്കിൽ പുതിയ ലീഫിന് കീഴിൽ പഴയ ഇടനില നൽകുന്നത് തുടരാം. രണ്ട് സാഹചര്യങ്ങളിലും ലീഫിന്റെ സ്വന്തം തീയതികൾ ന്യായമായി തോന്നുമ്പോൾ ചെയിൻ പരാജയപ്പെടുന്നു.
ലോഡ്-ബാലൻസ്ഡ് എൻഡ്പോയിന്റുകൾ ഇതിനെ തകർന്നതിൽ നിന്ന് പൊരുത്തക്കേടിലേക്ക് മാറ്റുന്നു. വീണ്ടും ശ്രമം വിജയിച്ചാലോ, ഒരു നെറ്റ്വർക്ക് പ്രവർത്തിച്ച് മറ്റൊന്ന് പ്രവർത്തിക്കുന്നില്ലെങ്കിലോ, ക്രമീകരണങ്ങൾ മാറ്റുന്നതിന് മുൻപ് ഏത് പിയർ ഉത്തരം നൽകി, ഏത് ചെയിൻ അയച്ചു എന്ന് രേഖപ്പെടുത്തുക. openssl s_client ബന്ധിപ്പിച്ച വിലാസം പ്രിന്റ് ചെയ്യുന്നു, അതിനാൽ കുറച്ച് ശ്രമങ്ങൾ ഓരോ നോഡും ഒരേ ചെയിൻ നൽകുന്നുണ്ടോ എന്ന് വെളിപ്പെടുത്തുന്നു.
പരിശോധന നിലനിർത്തുന്ന പരിഹാര പാതകൾ
ഘടികാര പ്രശ്നം ഉപകരണത്തിൽ പരിശോധന ഓണാക്കി വെച്ച് പരിഹരിക്കുന്നു. സർട്ടിഫിക്കറ്റ് പ്രശ്നം ഇപ്പോഴത്തെ ഉൾക്കൊള്ളുന്ന വിൻഡോയ്ക്ക് ഇഷ്യൂ ചെയ്ത വസ്തുവകകൾ കൊണ്ട് ഓപ്പറേറ്റർ പരിഹരിക്കുന്നു. ഏതെങ്കിലും ക്ലയന്റ് ക്രമീകരണം ഇപ്പോഴും സാധുവല്ലാത്ത സർട്ടിഫിക്കറ്റിനെ സാധുവാക്കുന്നില്ല; സമയ പരിശോധനകൾ ഒഴിവാക്കുന്ന ഫ്ലാഗുകൾ രോഗനിർണയം സ്ഥിരീകരിക്കാനാണ്, ഉത്പാദനത്തിലേക്ക് അയയ്ക്കാനല്ല.
സർട്ടിഫിക്കറ്റ് ആസൂത്രിത ആക്ടിവേഷനായി തയ്യാറാക്കിയിട്ടുണ്ടെങ്കിൽ, മാറ്റ പദ്ധതി പിന്തുടരുക. അതിന്റെ വിൻഡോ തുറക്കുമ്പോൾ ഇൻസ്റ്റാൾ ചെയ്യുക, അല്ലെങ്കിൽ ദാതാവ് രേഖപ്പെടുത്തിയ ഓവർലാപ്പ് നടപടിക്രമം ഉപയോഗിക്കുക, നേരത്തെ ഇൻസ്റ്റാൾ ചെയ്ത് ഉപയോക്താക്കളെ മുന്നറിയിപ്പുകളിലൂടെ ക്ലിക്ക് ചെയ്യാൻ പഠിപ്പിക്കുന്നതിന് പകരം. ആളുകൾ അവഗണിക്കാൻ പഠിക്കുന്ന മുന്നറിയിപ്പുകൾ ചെറിയ കാലതാമസത്തേക്കാൾ ചെലവേറിയതാണ്.
അവസാനമായി, പരാജയം സംഭവിച്ച അതേ രീതിയിൽ വീണ്ടും പരീക്ഷിക്കുക: പുതിയ സെഷൻ, അതേ ക്ലയന്റ്, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ട വിഭവം. TLS ലൈബ്രറികൾ കണക്ഷന്റെ ആയുസ്സ് മുഴുവൻ പരിശോധിച്ച ചെയിൻ കാഷെ ചെയ്തേക്കാം, പുനരാരംഭിച്ച സെഷൻ അത് വീണ്ടും പരിശോധിക്കണമെന്നില്ല, അതിനാൽ പഴയ സെഷൻ പരിഹാരത്തിന് ശേഷവും പരാജയപ്പെട്ടേക്കാം അല്ലെങ്കിൽ റിഗ്രഷന് ശേഷവും പ്രവർത്തിച്ചേക്കാം. വ്യൂവറിൽ തുറക്കുന്ന ഫയൽ ഫയൽ വായിക്കാമെന്ന് മാത്രം തെളിയിക്കുന്നു; പൂർത്തിയായ ഹാൻഡ്ഷേക്ക് ചെയിൻ സാധുതയുള്ളതാണെന്ന് തെളിയിക്കുന്നു.
ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: പരാജയപ്പെട്ട ഉപകരണത്തിന്റെ UTC സമയവും സമന്വയ അവസ്ഥയും, അവതരിപ്പിച്ച ചെയിനിലെ ഓരോ സർട്ടിഫിക്കറ്റിന്റെയും notBefore, notAfter, രണ്ടാം ക്ലയന്റിൽ നിന്ന് അതേ ചെയിൻ, പിശക് സർട്ടിഫിക്കറ്റിന് നൽകുന്ന പേര്. ഘടികാരം ശരിയും വിൻഡോ തുറന്നിട്ടില്ലെങ്കിൽ, ബാക്കി ഓപ്പറേറ്ററുടെ ജോലിയാണ്, നിങ്ങളുടെ ഭാഗത്ത് ശരിയായ നീക്കം പരിശോധന ദുർബലമാക്കുന്നതിന് പകരം വിൻഡോയ്ക്കായി കാത്തിരിക്കുകയാണ്.