പിന്തുണയ്ക്കാത്ത സർട്ടിഫിക്കറ്റ് ഉദ്ദേശ്യം: ഇന്റർമീഡിയറ്റ് CA എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

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

പരിശോധകൻ യഥാർത്ഥത്തിൽ നിരസിച്ച സർട്ടിഫിക്കറ്റ് ഏത്

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

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

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

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

ലീഫിന്റെ ഉദ്ദേശ്യവും ചെയിനിന്റെ നയവും രണ്ട് പരിശോധനകളാണ്

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

അതുകൊണ്ടാണ്, എല്ലാ ദൃശ്യ ഫീൽഡുകളിലും ശരിയായ ഒരു പുതിയ ലീഫ് സർട്ടിഫിക്കറ്റ് പോലും ഉടനടി പരാജയപ്പെടാവുന്നത്. അതുകൊണ്ടാണ് പരിഹാരം സാധാരണയായി VPN കോൺഫിഗറേഷനിലല്ല, മറിച്ച് ഇഷ്യൂ ചെയ്യുന്ന അതോറിറ്റിയുടെ പ്രൊഫൈലിലുള്ളത്.

ഇല്ലാത്ത EKU നിയന്ത്രണാത്മക EKU അല്ല

RFC 5280 വിപുലീകൃത കീ ഉപയോഗ എക്സ്റ്റൻഷൻ ഐച്ഛികമാക്കുന്നു, അത് ഉള്ളപ്പോൾ നിയന്ത്രണാത്മകവുമാണ്. അതിനാൽ എക്സ്റ്റൻഷൻ ഇല്ലാത്ത CA സർട്ടിഫിക്കറ്റ് സർവർ പ്രാമാണീകരണത്തോട് 'ഇല്ല' എന്ന് പറഞ്ഞിട്ടില്ല, അതേസമയം ബന്ധമില്ലാത്ത ഒരു ഉദ്ദേശ്യം മാത്രം പട്ടികപ്പെടുത്തുന്നത് വളരെ നിർദ്ദിഷ്ടമായ എന്തോ പറഞ്ഞിരിക്കുന്നു. ഈ രണ്ട് അവസ്ഥകളെ തുല്യമായി കാണുന്നത് തെറ്റായ രോഗനിർണയവും, അതിനെക്കാൾ മോശമായി തെറ്റായ പരിഹാരവും നൽകുന്നു. കൺസോളിൽ സമാനമായി കാണപ്പെടുന്ന രണ്ട് അതോറിറ്റികൾ ചെയിനിൽ തികച്ചും വ്യത്യസ്തമായി പെരുമാറുന്നതും ഈ വ്യത്യാസം വിശദീകരിക്കുന്നു.

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

വീണ്ടും ഇഷ്യൂ ചെയ്യുന്നതിന് മുൻപ് പരാജയം ഓഫ്ലൈനായി പുനർനിർമ്മിക്കുക

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

ഇഷ്യൂ നയം തിരുത്തുക, പരിശോധനാ വിളിയല്ല

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

പരിശോധന നിർത്തലാക്കുന്നത് മറ്റൊരു പ്രലോഭനമായ ഷോർട്ട്കട്ടാണ്, അത് സർട്ടിഫിക്കറ്റ് പ്രശ്നത്തെ വിശ്വാസ പ്രശ്നമാക്കി മാറ്റുന്നു. ഉദ്ദേശ്യ പരിശോധന അതേപടി നിലനിർത്തുക, ചെയിൻ തിരുത്തുക, പാത ഇപ്പോൾ ഉദ്ദേശിച്ച റോൾ സേവിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കാൻ അതേ ഓഫ്ലൈൻ പരിശോധന വീണ്ടും പ്രവർത്തിപ്പിക്കുക, അതിനുശേഷം സേവനം വീണ്ടും തൊടുക.