ലീഫ് സർട്ടിഫിക്കറ്റ് സാധുവാണ്, ചെയിൻ കാലഹരണപ്പെട്ടു: ആഴം വായിക്കുക

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

ആഴം പരാജയപ്പെട്ട സർട്ടിഫിക്കറ്റിനെ പേരിടുന്നു

OpenSSL ഡയഗ്നോസ്റ്റിക്സിൽ, ആഴം 0 ലക്ഷ്യ സർട്ടിഫിക്കറ്റും ആഴം 1 അതിൽ ഒപ്പിട്ട ഇഷ്യൂവറും ആണ്; വലിയ സംഖ്യകൾ ട്രസ്റ്റ് ആങ്കറിലേക്ക് തുടരുന്നു. ആഴം 1-ൽ റിപ്പോർട്ട് ചെയ്ത കാലഹരണം ലീഫിലെ നിലവിലുള്ള notAfter-ന് വിരുദ്ധമല്ല, അതിനാൽ ദൃശ്യമായ സർട്ടിഫിക്കറ്റ് വീണ്ടും പരിശോധിച്ചാൽ പിശക് ഒരിക്കലും വിശദീകരിക്കപ്പെടില്ല.

പരാജയപ്പെട്ട സർട്ടിഫിക്കറ്റിന്റെ വിരലടയാളം അതിന്റെ subject-നൊപ്പം രേഖപ്പെടുത്തുക, കാരണം വ്യത്യസ്ത സർട്ടിഫിക്കറ്റുകൾക്ക് ഒരേ CA പേര് ഉണ്ടാകാം. ക്രോസ്-സൈനിംഗ് കൃത്യമായി ആ സാഹചര്യം സൃഷ്ടിക്കുന്നു: അതേ അധികാരി ഒന്നിലധികം തവണ, വ്യത്യസ്ത സാധുതാ തീയതികളോടെ പ്രത്യക്ഷപ്പെടുന്നു, നിങ്ങൾ പ്രതീക്ഷിക്കാത്തതാണ് പരിശോധകൻ തിരഞ്ഞെടുത്തത്. പരിചിതമായ ലേബൽ ഐഡന്റിഫയറല്ല, ഒരേ പേര് പങ്കിടുന്ന രണ്ട് വസ്തുക്കളെ വേർതിരിക്കുന്നത് വിരലടയാളമാണ്.

ഒന്നിലധികം സർട്ടിഫിക്കറ്റ് റോളുള്ള ഉൽപ്പന്നങ്ങളിലും ശ്രദ്ധിക്കുക. OpenVPN Access Server-ൽ, വെബ് ഇന്റർഫേസുകളെ സംരക്ഷിക്കുന്ന സർട്ടിഫിക്കറ്റുകൾ VPN കണക്ഷനുകൾക്ക് ഉപയോഗിക്കുന്നവയിൽ നിന്ന് വേറിട്ടതാണ്, അതിനാൽ അഡ്മിൻ പേജ് തുറക്കുന്ന ബ്രൗസർ ടണലിന്റെ പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

ട്രസ്റ്റ് ഇൻപുട്ടുകൾ ചെയിൻ സ്ഥാനാർത്ഥികളിൽ നിന്ന് വ്യത്യസ്തമാണ്

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

ഡിഫോൾട്ട് പാതയും സ്റ്റോറും -no-CApath -no-CAstore ഉപയോഗിച്ച് പ്രവർത്തനരഹിതമാക്കുന്നത് പരിശോധനയെ സത്യസന്ധമായി നിർത്തുന്നു: ഫലം നിങ്ങൾ പേരിട്ട ഫയലുകളെ ആശ്രയിക്കുന്നു, വർക്ക്സ്റ്റേഷൻ യാദൃച്ഛികമായി വിശ്വസിക്കുന്നതിനെയല്ല. OpenSSL പരിശോധനാ റഫറൻസ് ഈ ഓപ്ഷനുകളും അവ ഉത്പാദിപ്പിക്കുന്ന ഡയഗ്നോസ്റ്റിക്സും രേഖപ്പെടുത്തുന്നു.

പരിശോധന വിജയിക്കുമ്പോൾ -show_chain നിർമ്മിച്ച ചെയിൻ അച്ചടിക്കുന്നു, പാത നിങ്ങൾ ഉദ്ദേശിച്ചതാണെന്ന് സ്ഥിരീകരിക്കാൻ ഇത് ഉപകരിക്കും. അത് പരാജയപ്പെടുമ്പോൾ, റിപ്പോർട്ട് ചെയ്ത ആഴവും subject-ഉം സൂക്ഷിക്കുക; ആ രണ്ട് ഫീൽഡുകൾ അടുത്ത വായനക്കാരനോട് ഏത് സർട്ടിഫിക്കറ്റ് പരിശോധിക്കണമെന്ന് പറയുന്നു.

ഇത് ചെയ്യാത്തത് ഓരോ ക്ലയന്റിന്റെയും നയം പുനർനിർമ്മിക്കുകയാണ്. പിൻ, ഉദ്ദേശ്യ പരിധി അല്ലെങ്കിൽ ക്ലയന്റ്-നിർദ്ദിഷ്ട ഐഡന്റിറ്റി പരിശോധന ക്ലയന്റിലാണ്, ഈ കമാൻഡിലല്ല. സർവറിൽ പരിശോധന വിജയിക്കുകയും കണക്ഷൻ പരാജയപ്പെടുകയും ചെയ്യുമ്പോൾ പരിശോധിക്കേണ്ട ക്രമീകരണങ്ങൾ അവയാണ്. രണ്ട് ഡയഗ്നോസുകളും വേർതിരിച്ച് നിർത്തുക, അല്ലാത്തപക്ഷം പിൻനിംഗ് പിശക് പിന്തുടർന്ന് ആരോഗ്യകരമായ സർട്ടിഫിക്കറ്റ് പുതുക്കും.

പരിശോധന എന്ത് തെളിയിക്കുന്നു, എന്ത് ഒഴിവാക്കുന്നു

ഇത് നിങ്ങൾ നൽകിയ ട്രസ്റ്റ് ഫയലിനെതിരായ പാതയും ഉദ്ദേശ്യവും പരിശോധിക്കുന്നതാണ്. HTTPS നാമ പരിശോധനയ്ക്ക് ഉചിതമായ ഓപ്ഷനിലൂടെ പ്രതീക്ഷിത ഹോസ്റ്റ്നെയിം ചേർക്കുക; VPN കണക്ഷനായി ക്ലയന്റിന്റെ കോൺഫിഗർ ചെയ്ത ഐഡന്റിറ്റി പരിശോധനകൾ നിലനിർത്തി ആ ക്ലയന്റ് യഥാർത്ഥത്തിൽ വായിക്കുന്ന ട്രസ്റ്റ് മെറ്റീരിയൽ ഉപയോഗിക്കുക.

സർവർ അയക്കുന്നത് സ്ഥാനാർത്ഥികളുടെ ഒരു കൂട്ടമാണ്, നിങ്ങളുടെ ക്ലയന്റ് ഒടുവിൽ നിർമ്മിക്കുന്ന പാതയല്ല. പ്രാദേശിക ട്രസ്റ്റും ലൈബ്രറിയുടെ നിർമ്മാണ നിയമങ്ങളും രണ്ടും ഫലത്തെ രൂപപ്പെടുത്തുന്നു, അതിനാൽ ഒരേ പ്രതികരണം ഒരു യന്ത്രത്തിൽ പരിശോധിക്കപ്പെടാം മറ്റൊന്നിൽ പരാജയപ്പെടാം. സമാനമായ വിലയിരുത്തൽ അനുമാനിക്കുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന ക്ലയന്റിന്റെ പരിപാലിത ട്രസ്റ്റ് സ്റ്റോറും TLS നടപ്പാക്കലും പ്രവർത്തിക്കുന്ന ക്ലയന്റിന്റേതുമായി താരതമ്യം ചെയ്യുക. അവിടത്തെ വ്യത്യാസം „ഈ ലാപ്ടോപ്പിൽ മാത്രം പരാജയപ്പെടുന്നു“ എന്ന നിരവധി റിപ്പോർട്ടുകൾ വിശദീകരിക്കുന്നു.

ഓരോ സർട്ടിഫിക്കറ്റിന്റെയും വിൻഡോ ഒന്നൊന്നായി കാണുന്നതിന് പകരം ഒരു കൂട്ടമായി അച്ചടിക്കുക:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

ആ രണ്ടാമത്തെ കമാൻഡ് ഓരോ ഫയലും കൈകൊണ്ട് ഡീകോഡ് ചെയ്യാതെ subject-കളും ഇഷ്യൂവർമാരും ലിസ്റ്റ് ചെയ്യുന്നു, അങ്ങനെ ലീഫ് ഇപ്പോഴും നന്നായി തോന്നുമ്പോൾ തീയതി കഴിഞ്ഞ ഇടനില സർട്ടിഫിക്കറ്റ് നിങ്ങൾ കണ്ടെത്തുന്നു.

പരിശോധന ദുർബലമാക്കാതെ പാത നന്നാക്കുക

കാലഹരണപ്പെട്ട ഇടനില അല്ലെങ്കിൽ പഴയ ക്രോസ്-സൈൻ ചെയ്ത സർട്ടിഫിക്കറ്റ് നൽകുമ്പോൾ, ഇഷ്യൂവറുടെ നിലവിൽ പിന്തുണയ്ക്കുന്ന ചെയിൻ നേടി സേവനത്തിന്റെ രേഖപ്പെടുത്തിയ സർട്ടിഫിക്കറ്റ് വർക്ക്ഫ്ലോ വഴി വിന്യസിക്കുക. ക്ലയന്റിന് ഉദ്ദേശിച്ച പരിപാലിത ആങ്കർ ഇല്ലെങ്കിൽ, അതിന്റെ നിർവഹിത ട്രസ്റ്റ് കോൺഫിഗറേഷനോ ക്ലയന്റ് സോഫ്റ്റ്വെയറോ അപ്ഡേറ്റ് ചെയ്യുക. സന്ദേശം നിശബ്ദമാക്കാൻ മാത്രം ബണ്ടിലിലെ എല്ലാ സർട്ടിഫിക്കറ്റുകളും റൂട്ടായി അടയാളപ്പെടുത്തുന്ന ഷോർട്ട്കട്ടിനെ എതിർക്കുക.

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

മാറ്റത്തിന് ശേഷം, ബാധിത ക്ലയന്റിൽ പുതിയ പ്രാമാണീകരണം നിർബന്ധമാക്കി പ്രത്യേക കാലഹരണ സന്ദേശം പോയെന്ന് സ്ഥിരീകരിക്കുക. ലീഫ് തന്നെ അനുയോജ്യമല്ലെങ്കിൽ മാത്രം ലീഫ് പുതുക്കുക. സമയ പരിശോധനകൾ പ്രവർത്തനരഹിതമാക്കുന്നതോ ചരിത്രപരമായ ക്രോസ് സർട്ടിഫിക്കറ്റ് പുനഃസ്ഥാപിക്കുന്നതോ സാധുവായ നിലവിലെ പാത സൃഷ്ടിക്കുന്നില്ല; അത് അടുത്ത പരാജയം വൈകിപ്പിക്കുന്നു മാത്രം.