സ്വയം ഒപ്പിട്ട ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്? VPN സെർവർ ഇപ്പോഴും അത് നിരസിക്കുന്നു

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

വിശ്വാസം സെർവറിലാണ്, നിങ്ങളുടെ പ്രൊഫൈലിലല്ല

സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണം ഒരു താരതമ്യമാണ്. ക്ലയന്റ് ഒരു സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു; ഗേറ്റ്വേ അത് അതിന്റെ കോൺഫിഗറേഷനിലെ ഒരു CA ഒപ്പിട്ടോ എന്ന് പരിശോധിക്കുന്നു.

നിങ്ങളുടെ പ്രൊഫൈൽ സെർവർ പരിശോധിക്കാൻ ക്ലയന്റ് ഉപയോഗിക്കേണ്ട CA ഫയൽ പേര് നൽകുന്നു. സെർവർ നിങ്ങളെ പരിശോധിക്കാൻ ഉപയോഗിക്കേണ്ട CA യുടെ പേര് അതിന് നൽകാനാവില്ല. കോൺഫിഗറേഷന്റെ ആ പകുതി നിങ്ങളുടേതല്ല.

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

സ്വയം ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് എന്തുകൊണ്ട് അതിനെ മാറ്റിസ്ഥാപിക്കാനാവില്ല

സ്വയം ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് അതിന്റെ സ്വന്തം കീ കൊണ്ട് ഒപ്പിടുന്നു. ഒപ്പ് അതേ ഫയലിനെതിരെ പരിശോധിക്കുന്നു, ഇത് അതിനെ സ്വയം-സ്ഥിരതയുള്ളതാക്കുകയും മറ്റൊരാളുടെ ഗേറ്റ്വേയ്ക്കുള്ള യോഗ്യതയായി ഉപയോഗശൂന്യമാക്കുകയും ചെയ്യുന്നു.

ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് ആന്തരികമായി സ്ഥിരതയുള്ളതാണോ എന്ന് ചോദിക്കുന്നില്ല. വിശ്വസനീയമായ ഒരു ഇഷ്യു ചെയ്യുന്നയാൾ അത് ഒപ്പിട്ടോ എന്ന് ചോദിക്കുന്നു.

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

CSR വഴി നിങ്ങളുടെ സ്വകാര്യ കീ സൂക്ഷിക്കുന്നു

ജോലിയുടെ ഭൂരിഭാഗവും ഇപ്പോഴും പ്രാദേശികമായി ചെയ്യാം. ഒരു കീ ജോഡി നിർമ്മിക്കുക, പൊതു പകുതിയ്ക്ക് ചുറ്റും ഒരു സർട്ടിഫിക്കറ്റ് ഒപ്പിടൽ അഭ്യർത്ഥന നിർമ്മിക്കുക, ആ അഭ്യർത്ഥന ഓപ്പറേറ്റർക്ക് അയയ്ക്കുക. അഭ്യർത്ഥന മാത്രം നിങ്ങളുടെ യന്ത്രം വിട്ടുപോകുന്നു. സ്വകാര്യ പകുതി നിങ്ങൾ നിർമ്മിച്ചിടത്ത് തന്നെ തുടരുന്നു.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

ഓപ്പറേറ്റർ സ്വന്തം CA ഉപയോഗിച്ച് അഭ്യർത്ഥന ഒപ്പിട്ട് ഒരു സർട്ടിഫിക്കറ്റ് തിരികെ നൽകുന്നു. നിങ്ങളുടെ സ്വകാര്യ കീ ഒരിക്കലും യാത്ര ചെയ്തിട്ടില്ല, ഫലം ഗേറ്റ്വേ വിശ്വസിക്കുന്ന ആങ്കറിലേക്ക് ചങ്ങലയാകുന്നു.

മാനേജ്ഡ് സേവനങ്ങൾ പലപ്പോഴും CSR ഒഴിവാക്കി മുഴുവൻ ബണ്ടിലും നൽകുന്നു. അതേ ദാതാവ് തന്നെ ടണൽ അവസാനിപ്പിച്ച് CA കൈവശം വയ്ക്കുമ്പോൾ അത് ന്യായമായ കൈമാറ്റമാണ്. കീ സൂക്ഷിക്കുന്നതുകൊണ്ട് അതിന്റെ സൂക്ഷ്മത മെച്ചപ്പെടുന്നില്ല, കാരണം ദാതാവിന് എപ്പോൾ വേണമെങ്കിലും പുതിയത് നിർമ്മിക്കാം.

ബണ്ടിലുകൾ ഇറക്കുമതി ചെയ്യുന്നു, ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല

സുരക്ഷിതമെന്ന് തോന്നുന്ന പേരുള്ള വെണ്ടർ ബണ്ടിലുകൾ പലപ്പോഴും OpenVPN പ്രൊഫൈലുകളാണ്. അവയിൽ കോൺഫിഗറേഷനും ചിലപ്പോൾ സർട്ടിഫിക്കറ്റുകളും അടങ്ങിയിരിക്കുന്നു, അവ ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല. പ്രോട്ടോക്കോൾ സംസാരിക്കുന്ന ക്ലയന്റിലേക്ക് ഫയൽ ഇറക്കുമതി ചെയ്യുക, കണക്ഷൻ കോൺഫിഗർ ചെയ്യപ്പെടും.

കൈകാര്യം ചെയ്യാനുള്ള നിയമം ഉള്ളടക്കത്തിൽ നിന്നാണ് വരുന്നത്. പ്രൊഫൈലിൽ സ്വകാര്യ കീ ഉൾച്ചേർത്തിരിക്കുകയാണെങ്കിൽ അത് ഒരു യോഗ്യതയാണ്, പാസ്വേഡിന് നൽകുന്ന അതേ ശ്രദ്ധ അർഹിക്കുന്നു: ഇമെയിൽ ഇല്ല, സംഭരണി ഇല്ല, പങ്കിട്ട ഡൗൺലോഡ് ഫോൾഡർ ഇല്ല. ഓപ്പറേറ്റർ ca.crt, client.crt, client.key എന്നിവ വെവ്വേറെ നൽകുമ്പോൾ അവ നിയന്ത്രിതാനുമതികളോടെ ഒരുമിച്ച് സൂക്ഷിക്കുക, പ്രൊഫൈൽ അവയിലേക്ക് ചൂണ്ടിക്കാണിക്കുക.

ഓപ്പറേറ്റർ ഒഴിവാക്കിയേക്കാവുന്ന പരിശോധനകൾ ചേർക്കുക

റൗട്ടർ നിർമ്മിച്ച പ്രൊഫൈലിൽ ചിലപ്പോൾ പിയർ പരിശോധന ഇല്ല. remote-cert-tls server പിയർ സർട്ടിഫിക്കറ്റിൽ സെർവർ പ്രാമാണീകരണ ഉദ്ദേശ്യം ഉണ്ടായിരിക്കണമെന്ന് ആവശ്യപ്പെടുന്നു, അതിനാൽ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് സെർവറായി വീണ്ടും പ്ലേ ചെയ്യാനാവില്ല. ആ ഒരു വരി വ്യക്തമായ ന്യായീകരണമുള്ള ചെറിയ മാറ്റമാണ്.

verify-x509-name ഓപ്പറേറ്റർക്ക് പ്രതീക്ഷിക്കുന്ന വിഷയമോ SAN ഓ പേര് നൽകാനാകുമ്പോൾ കൂടുതൽ മുന്നോട്ട് പോകുന്നു. രണ്ടും പ്രൊഫൈലിലേക്കുള്ള ചെറിയ കൂട്ടിച്ചേർക്കലുകളാണ്, രണ്ടും ന്യായീകരിക്കാവുന്നതാണ്. ഇറക്കുമതി ചെയ്യുന്നതിന് മുമ്പ് ലഭിച്ചത് പരിശോധിക്കുക.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

പരിശോധനാ ക്രമീകരണങ്ങൾ തകർന്ന ചങ്ങലയുടെ അറ്റകുറ്റപ്പണിയല്ല. ഇഷ്യുവർ തെറ്റാണെങ്കിൽ ഉത്തരം ശരിയായ CA യിൽ നിന്നുള്ള സർട്ടിഫിക്കറ്റാണ്, പരിശോധന ഓഫാക്കുന്ന ഒരു ഫ്ലാഗല്ല. പരിശോധന ഓഫാക്കുന്നത് പ്രാമാണീകരണ പരാജയത്തെ കണ്ടെത്താത്ത പരാജയമാക്കി മാറ്റുന്നു.

ഒരു ബണ്ടിൽ ആവശ്യപ്പെടുക: PEM രൂപത്തിൽ അധികാരിയുടെ സർട്ടിഫിക്കറ്റ്, ആ അധികാരി ഒപ്പിട്ട ക്ലയന്റ് സർട്ടിഫിക്കറ്റ്, നിങ്ങൾ നിർമ്മിച്ചതോ നിങ്ങൾ വിശ്വസിക്കുന്ന ചാനലിലൂടെ വന്നതോ ആയ ഒരു കീ, സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കേണ്ട കൃത്യമായ സെർവർ നാമം. അതേ സന്ദേശത്തിൽ കാലാവധി തീരുന്ന തീയതി രേഖപ്പെടുത്തുക, കാലാവധി കഴിഞ്ഞ സർട്ടിഫിക്കറ്റ് മാസങ്ങൾക്ക് ശേഷം നെറ്റ്വർക്ക് തകരാറായി തോന്നുന്നു.