VPN സർട്ടിഫിക്കറ്റ് അതോറിറ്റി മാറ്റുമ്പോൾ എന്ത് സംഭവിക്കുന്നു

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

ഒരു മാറ്റം, രണ്ട് വേറിട്ട മാറ്റങ്ങൾ

സർട്ടിഫിക്കറ്റ് അതോറിറ്റി എന്നത് ഒരു പേര്, ഒരു പൊതു കീ, ഒപ്പിടുന്ന സ്വകാര്യ കീ എന്നിവയാണ്. വാലിഡേറ്റർമാർ ‘CA’ എന്ന സാമാന്യത്തെ ഒരിക്കലും വിശ്വസിക്കുന്നില്ല. വിശ്വാസ സംഭരണിയിൽ ഇതിനകം ഉള്ള ഒരു നിർദ്ദിഷ്ട സർട്ടിഫിക്കറ്റിനെ അവർ വിശ്വസിക്കുന്നു, ഒപ്പുകളുടെ ശൃംഖല ആ സംഭരിച്ച പകർപ്പിൽ എത്തുമ്പോൾ മാത്രം ഇഷ്യൂവറെ സ്വീകരിക്കുന്നു. അതിനാൽ CA മാറ്റം സ്വതന്ത്രമായി പരാജയപ്പെടുന്ന രണ്ട് കാര്യങ്ങളെ മാറ്റുന്നു: ഏത് ആങ്കറുകൾ സ്വീകരിക്കുന്നു, ഏത് പങ്കാളി ഐഡന്റിറ്റികൾ അവയുടെ കീഴിൽ പുറപ്പെടുവിച്ചു.

മിക്ക VPN വിന്യാസങ്ങളും രണ്ട് ദിശകളിലും പരിശോധിക്കുന്നു. ക്ലയന്റ് ഗേറ്റ്‌വേയുടെ സർട്ടിഫിക്കറ്റും ഗേറ്റ്‌വേ ക്ലയന്റിന്റേതും പ്രാമാണീകരിക്കുന്നു. ക്ലയന്റ് ബണ്ടിൽ മാത്രം പുതുക്കുന്ന മാറ്റം, പഴയ CA ഐഡന്റിറ്റി ഇപ്പോഴും അവതരിപ്പിക്കുന്ന എല്ലാ ക്ലയന്റിനെയും സർവർ നിരസിക്കാൻ വിടുന്നു, വിപരീതവും അത്രതന്നെ സാധാരണമാണ്. ആദ്യം നിർവ്വഹണ പോയിന്റുകൾ പട്ടികപ്പെടുത്തുക: ക്ലയന്റ് വിശ്വാസ സംഭരണികൾ, ഗേറ്റ്‌വേയുടെ ca ഫയൽ, അതിന് മുന്നിൽ TLS അവസാനിപ്പിക്കുന്ന ഏത് പ്രോക്സിയും, പുറത്തുനിന്ന് അന്തിമ പോയിന്റ് പരിശോധിക്കുന്ന പ്രോബും.

വാലിഡേറ്റർ എന്ത് പരിശോധിക്കുന്നു, ക്രമത്തിൽ

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

ആ യാത്ര ഓഫ്‌ലൈനായി ആവർത്തിക്കാൻ, -CAfile നിങ്ങൾ വിന്യസിക്കാൻ പോകുന്ന കൃത്യമായ ബണ്ടിലിലേക്ക് ചൂണ്ടിക്കാണിക്കുക, സിസ്റ്റം സംഭരണിയിലേക്കല്ല. അല്ലെങ്കിൽ നിങ്ങൾ മാറ്റമല്ല, ഹോസ്റ്റാണ് പരീക്ഷിക്കുന്നത്:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

ആ കമാൻഡ് ഗേറ്റ്‌വേയുടെ HTTPS അഡ്മിൻ പേജ് പോലുള്ള സാധാരണ TLS ശ്രോതാവിനെതിരെ മാത്രം പ്രവർത്തിക്കുന്നു; OpenVPN നിയന്ത്രണ ചാനൽ TLS-ന് മുൻപാണ്, അതിനാൽ s_client-ന് ടണലിന്റെ ഹാൻഡ്ഷേക്ക് പരിശോധിക്കാനാവില്ല.

ആ പിഴവുകൾക്ക് പിന്നിലെ പാത്ത് നിർമ്മാണ നിയമങ്ങൾ RFC 5280 വിഭാഗം 6 ൽ ഉണ്ട്. അല്ലാത്തപക്ഷം ഏകപക്ഷീയമായി തോന്നുന്ന പരാജയങ്ങളെ അവ വിശദീകരിക്കുന്നു: ആരും ഓർത്തിരിക്കാത്ത കാലഹരണപ്പെട്ട ഇടനിലക്കാരൻ, കീ ഉപയോഗം ഒപ്പിടൽ വിലക്കുന്ന സർട്ടിഫിക്കറ്റ്, അല്ലെങ്കിൽ നിങ്ങൾ പരിശോധിക്കുന്ന ഹോസ്റ്റിനെ ഒഴിവാക്കുന്ന നാമ നിയന്ത്രണം.

പഴയ ടണൽ എന്തുകൊണ്ട് പ്രവർത്തനം തുടരുന്നു

TLS-ഉം OpenVPN-ഉം ഹാൻഡ്ഷേക്ക് കഴിഞ്ഞതിന് ശേഷവും സ്ഥാപിത സെഷൻ ജീവനോടെ നിലനിർത്തുന്നു. ഓരോ പാക്കറ്റിനും പങ്കാളിയുടെ സർട്ടിഫിക്കറ്റ് ഒന്നും വീണ്ടും പരിശോധിക്കുന്നില്ല, അതിനാൽ മാറ്റത്തിന് മുൻപ് ബന്ധിപ്പിച്ച ക്ലയന്റ്, വീണ്ടും ചർച്ചയോ വീണ്ടും ബന്ധിപ്പിക്കലോ ടണൽ വീഴലോ ഉണ്ടാകുന്നതുവരെ ട്രാഫിക് കടത്തിവിടുന്നു. ഈ വിടവാണ് CA മാറ്റം ഒരു മണിക്കൂർ നന്നായി തോന്നി പിന്നീട് ഏറ്റവും മോശം നിമിഷത്തിൽ പരാജയപ്പെടാൻ കാരണം: ലാപ്‌ടോപ്പ് ഉറക്കത്തിൽ നിന്ന് ഉണരുന്നു, NAT മാപ്പിംഗ് കാലഹരണപ്പെടുന്നു, ഗേറ്റ്‌വേ പുനരാരംഭിക്കുന്നു.

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

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

വിഷയ നാമം വീണ്ടും ഉപയോഗിക്കുന്ന കെണി

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

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

നെറ്റ്‌വർക്ക് വീഴ്ത്താത്ത റൊട്ടേഷൻ

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

ആ ക്രമത്തിൽ ചെയ്താൽ ഓരോ ഘട്ടവും പിൻവലിക്കാവുന്നതാണ്. നിങ്ങൾ ഒഴിവാക്കുന്ന പരാജയം ഒരേസമയ മാറ്റമാണ്: ബണ്ടിൽ അപ്ഡേറ്റ് വിട്ടുപോയ ക്ലയന്റ്, പഴയ ആങ്കർ ഇതിനകം നീക്കിയ ഗേറ്റ്‌വേയെ നേരിടുന്നു, ഹാൻഡ്ഷേക്ക് മരിക്കുന്നു, ഏത് ഭാഗമാണ് പഴയതെന്ന് ഒരു ലോഗും പറയുന്നില്ല.

എതിർദിശയിൽ നീക്കം ചെയ്യുക. അതിജീവിക്കേണ്ട ഓരോ ഐഡന്റിറ്റിയും വീണ്ടും പുറപ്പെടുവിക്കുക, ഓരോന്നും പുതിയ ശൃംഖല അവതരിപ്പിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, പിന്നീട് ബണ്ടിലുകളിൽ നിന്ന് പഴയ ആങ്കർ നീക്കുക. പഴയ CA-യുടെ സ്വകാര്യ കീ സേവനത്തിൽ നിന്ന് പുറത്താക്കുക, കാരണം ഇപ്പോഴും ഒപ്പിടാൻ കഴിയുന്ന ഇഷ്യൂവർ റൊട്ടേഷൻ പൂർത്തിയായിട്ടില്ലെന്ന് അർത്ഥം. ഓഡിറ്റിനായി സർട്ടിഫിക്കറ്റുകളും ഇഷ്യൂ രേഖകളും സൂക്ഷിക്കുക. നഷ്ടപ്പെട്ട ഇഷ്യൂവർ അതേ വിശ്വാസത്തിലേക്ക് പുനഃസ്ഥാപിക്കപ്പെടുന്നു; വെളിപ്പെടൽ പുതിയ ഐഡന്റിറ്റികൾ ആവശ്യപ്പെടുന്നു, പഴയ ആങ്കറിലേക്ക് മടക്കമില്ല.

ഫലം പരിശോധിക്കുക, ഫയൽ പട്ടികയല്ല

പ്രതീക്ഷിത ഡയറക്ടറിയിലുള്ള വിശ്വാസ ഫയൽ വളരെ കുറച്ച് മാത്രം തെളിയിക്കുന്നു. അപ്ലിക്കേഷൻ മറ്റൊരു പാത്ത്, മറ്റൊരു ഫോർമാറ്റ്, അല്ലെങ്കിൽ അപ്‌ഗ്രേഡ് മാറ്റിസ്ഥാപിക്കുന്ന പാക്കേജിനുള്ളിലെ പകർപ്പ് വായിച്ചേക്കാം. ഫയൽ ഉണ്ടോ എന്നല്ല, രണ്ട് അറ്റങ്ങളിലെ പെരുമാറ്റം പരിശോധിക്കുക.

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

ഒരിക്കലും കണക്ട് ചെയ്യാത്ത ഒരു ക്ലയന്റോടെ അവസാനിപ്പിക്കുക: അതിന്റെ പ്രൊഫൈൽ അവസ്ഥ മായ്ച്ച്, കണക്ട് ചെയ്ത്, ചർച്ച ചെയ്ത ശൃംഖല വായിക്കുക. കാഷെ ചെയ്ത സെഷൻ പുനരാരംഭിക്കുന്ന പങ്കാളി, ഒന്നും പരിശോധിക്കാതെയും മാറ്റം വിജയിച്ചുവെന്ന് സന്തോഷത്തോടെ റിപ്പോർട്ട് ചെയ്യും.