പുതുക്കിയ VPN സർട്ടിഫിക്കറ്റ്: ചില ക്ലയന്റുകൾ ഇപ്പോഴും അത് നിരസിക്കുന്നു

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

ഒരു പുതുക്കൽ, രണ്ട് സ്വഭാവങ്ങൾ

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

പരാജയപ്പെട്ട ക്ലയന്റ് ഏത് പ്രൊഫൈൽ തിരഞ്ഞെടുത്തുവെന്നും പരിശോധിക്കുക. സ്വന്തം സ്റ്റോറിലുള്ള ഇംപോർട്ട് ചെയ്ത പകർപ്പ്, അഡ്മിനിസ്ട്രേറ്റർ യഥാർത്ഥ ഫയൽ മറ്റൊരിടത്ത് എഡിറ്റ് ചെയ്യുമ്പോൾ മാറുന്നില്ല.

പുതുക്കൽ തീയതി മാത്രമല്ല, ഒബ്ജക്റ്റ് മാറ്റിസ്ഥാപിക്കുന്നു

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

ക്ലയന്റ് എന്താണ് പിൻ ചെയ്യുന്നതെന്ന് വായിക്കുക

ചില ക്ലയന്റുകൾ തങ്ങളുടെ പ്രൊഫൈലിൽ ഫിംഗർപ്രിന്റ് സൂക്ഷിച്ച് ഓരോ കണക്ഷനിലും താരതമ്യം ചെയ്യുന്നു. മറ്റുള്ളവർ അത് പ്ലാറ്റ്ഫോം ട്രസ്റ്റ് സ്റ്റോറിൽ സൂക്ഷിക്കുന്നു, വീണ്ടും ചിലർ CA-യെ മാത്രം ആശ്രയിക്കുന്നു. ഓരോ സന്ദർഭത്തിലും അറ്റകുറ്റപ്പണി വ്യത്യസ്തമാണ്, അതിനാൽ ആദ്യം സംവിധാനം തിരിച്ചറിയുക.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

ഓരോ ബാക്കെൻഡും നൽകുന്ന സർട്ടിഫിക്കറ്റ് താരതമ്യം ചെയ്യുക

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

നിയന്ത്രിത പാതയിലൂടെ വിശ്വാസം മാറ്റുക

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

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