SoftEther ServerCertSet: vpncmd ഉപയോഗിച്ച് പുതുക്കിയ ശൃംഖല ഇറക്കുമതി ചെയ്യുക

Certbot വിജയകരമായ പുതുക്കൽ റിപ്പോർട്ട് ചെയ്യുന്നു, ഡിസ്കിലെ ഫയലുകൾക്ക് പുതിയ തീയതികളുണ്ട്, എന്നിട്ടും ക്ലയന്റുകൾ ഇപ്പോഴും പഴയ ഐഡന്റിറ്റി കാണുന്നു. SoftEther തന്റെ SSL സെർവർ സർട്ടിഫിക്കറ്റ് തന്റെ സ്വന്തം സെർവർ-തല ക്രമീകരണത്തിൽ സൂക്ഷിക്കുന്നു, അതിനാൽ ഡിസ്കിലെ പുതിയ ഫയൽ ഇലയും അതിന്റെ കീയും ഇറക്കുമതി ചെയ്യുന്നതുവരെ ഒന്നും മാറ്റുന്നില്ല. താഴെയുള്ള ക്രമം ഒരു കൈകൊണ്ടുള്ള ഇറക്കുമതി, ഓരോ പുതുക്കലിനും ശേഷം പ്രവർത്തിക്കുന്ന ഒരു പൊതിയും, ശ്രോതാവ് യഥാർത്ഥത്തിൽ എന്താണ് അവതരിപ്പിക്കുന്നതെന്ന് വായിക്കുന്ന ഒരു പരിശോധനയും ഉൾക്കൊള്ളുന്നു. ഓരോ ഘട്ടവും അടുത്ത പുതുക്കലിന് ശേഷം താരതമ്യം ചെയ്യാവുന്ന തെളിവുകൾ അവശേഷിപ്പിക്കുന്നു.

പുതുക്കിയ ഫയൽ സെർവറിന്റെ ഐഡന്റിറ്റി മാറ്റുന്നില്ല

ഇഷ്യൂ ചെയ്യലും വിന്യസിക്കലും വെവ്വേറെ സംഭവങ്ങളാണ്, വെവ്വേറെ പരാജയ രീതികളോടെ. ACME ക്ലയന്റ് ഫയലുകൾ ഒരു വംശ പട്ടികയിൽ എഴുതി വിജയം രേഖപ്പെടുത്തുന്നു; SoftEther തന്റെ ക്രമീകരണത്തിലേക്ക് അവസാനം ലോഡ് ചെയ്ത സർട്ടിഫിക്കറ്റ് തന്നെ തുടർന്നും ഉപയോഗിക്കുന്നു. അതിനാൽ പൂജ്യം എക്സിറ്റ് സ്റ്റാറ്റസ് ഫയലുകളെ വിവരിക്കുന്നു, സേവനത്തെയല്ല, ആരും നോക്കാത്തിടത്തോളം ഈ രണ്ടും യോജിക്കാതിരിക്കാം. ഇറക്കുമതിയെ വിന്യാസ ഘട്ടമായും പുതുക്കലിനെ അതിന്റെ ഇൻപുട്ടായും കാണുക.

ആ വ്യത്യാസം ആശയക്കുഴപ്പമുള്ള പകുതി-പരാജയത്തെയും വിശദീകരിക്കുന്നു: പഴയ സർട്ടിഫിക്കറ്റ് അതിന്റെ കാലാവധി വരെ പ്രവർത്തിക്കുന്നു, അതിനാൽ തുടക്കത്തിൽ ഒന്നും തകർന്നതായി തോന്നുന്നില്ല. കാലാവധി തീരുമ്പോൾ എല്ലാ ക്ലയന്റുകളും ഒരുമിച്ച് പരാജയപ്പെടുന്നു, അത് വിട്ടുപോയ വിന്യാസ ഘട്ടത്തെക്കാൾ ഒരു തടസ്സം പോലെ തോന്നുന്നു. ഓരോ പുതുക്കലിനും ശേഷം അവതരിപ്പിച്ച ഐഡന്റിറ്റി പരിശോധിക്കുന്നത് ആ അത്ഭുതത്തെ സാധാരണ നിരീക്ഷണമാക്കി മാറ്റുന്നു.

ശ്രോതാവിന് യോജിക്കുന്ന വെല്ലുവിളി തിരഞ്ഞെടുക്കുക

സർട്ടിഫിക്കറ്റിൽ ക്ലയന്റുകൾ പരിശോധിക്കുന്ന ഹോസ്റ്റിന്റെ പേര് ഉണ്ടായിരിക്കണം, അതിനാൽ ആന്തരിക ലേബലിനോ വിലാസത്തിനോ പകരം പൊതു DNS നാമം ഉപയോഗിക്കുക. HTTP-01 ന് വെല്ലുവിളിക്ക് ഒരു നിമിഷം പോർട്ട് 80-ൽ ഉത്തരം നൽകണം, അത് താൽക്കാലിക ശ്രോതാവാണ്, SoftEther-ന്റെ സ്വന്തം പോർട്ട് നീക്കാനുള്ള കാരണമല്ല. DNS-01 ഒരു റെക്കോർഡിലൂടെ നിയന്ത്രണം തെളിയിക്കുന്നു, ഇൻബൗണ്ട് HTTP ഒട്ടും ആവശ്യമില്ല.

മേൽനോട്ടമില്ലാത്ത പുതുക്കൽ എന്നാൽ ഒരു മേഖലയിലേക്ക് പരിമിതപ്പെടുത്തിയ ക്രെഡൻഷ്യലുകളുള്ള ഓട്ടോമേറ്റഡ് DNS സംയോജനമാണ്, ഓരോ രണ്ടു മാസത്തിലും കൈകൊണ്ട് ടൈപ്പ് ചെയ്യുന്ന TXT റെക്കോർഡല്ല. വൈൽഡ്കാർഡ് വെല്ലുവിളിയുടെ തരം മാറ്റുന്നു, ആ ഓട്ടോമേഷന്റെ ആവശ്യകതയല്ല. ആദ്യ സർട്ടിഫിക്കറ്റ് നിലവിൽ വരുന്നതിന് മുമ്പ് ഇത് തീരുമാനിക്കുക, കാരണം പിന്നീട് വെല്ലുവിളിയുടെ തരം മാറ്റുന്നത് ക്ലയന്റ് ക്രമീകരണവും ഫയർവാളും ഒരുമിച്ച് സ്പർശിക്കലാണ്.

ഇവിടെയുള്ളപ്പോൾ ആർട്ടിഫാക്ടുകൾ ചിട്ടയായി സൂക്ഷിക്കുക. ഇലയും ഇന്റർമീഡിയറ്റ് സർട്ടിഫിക്കറ്റുകളും വെവ്വേറെ ഫയലുകളായും ഒരു സംയോജിത ശൃംഖല ഫയലായും വരുന്നു, സ്വകാര്യ കീ വീണ്ടും വെവ്വേറെയാണ്, ഇറക്കുമതിക്ക് അതിന് യോജിക്കുന്ന കീയുള്ള ശൃംഖല വേണം, ഒറ്റ പൊതു സർട്ടിഫിക്കറ്റല്ല.

സെർവർ തലത്തിൽ ശൃംഖല ഇറക്കുമതി ചെയ്യുക

സർട്ടിഫിക്കറ്റ് സ്പർശിക്കുന്നതിന് മുമ്പ് സെർവർ ക്രമീകരണത്തിന്റെ ബാക്കപ്പ് എടുത്ത് മാനേജ്മെന്റ് ഇന്റർഫേസിൽ ഇപ്പോഴും എത്താമെന്ന് ഉറപ്പാക്കുക. Virtual Hub അഡ്മിനിസ്ട്രേറ്ററായല്ല, സെർവർ അഡ്മിനിസ്ട്രേറ്ററായി ബന്ധിപ്പിക്കുക, കാരണം സർട്ടിഫിക്കറ്റ് സെർവർ ഒബ്ജക്ടിന്റേതാണ്. തുടർന്ന് ശൃംഖലയും കീയും സമ്പൂർണ പാതയിൽ ലോഡ് ചെയ്യുക, കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന് വായിക്കാവുന്ന ഫയലുകളിൽ നിന്ന്. പാതകൾ സമ്പൂർണമാണ്, കാരണം കമാൻഡ് അവ vpncmd പ്രവർത്തിപ്പിച്ച പ്രോസസിന്റെ വർക്കിംഗ് ഡയറക്ടറിയിൽ നിന്ന് പരിഹരിക്കുന്നു:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

വിന്യാസം ഹുക്ക് ചെയ്യുക, പുതുക്കലല്ല

കൈകൊണ്ടുള്ള ഇറക്കുമതി പ്രവർത്തിച്ചാൽ, ആ ഘട്ടങ്ങൾ തന്നെ ഒരു ചെറിയ പൊതിയിൽ ഇട്ട് വിജയകരമായ പുതുക്കലിന് ശേഷം ACME ക്ലയന്റിൽ നിന്ന് അത് വിളിക്കുക. Certbot ഹൂക്കിനായി RENEWED_LINEAGE, RENEWED_DOMAINS എന്നിവ സജ്ജീകരിക്കുന്നു, അതിനാൽ പലതും കൈകാര്യം ചെയ്യുന്ന യന്ത്രത്തിൽ പൊതിക്ക് ഒരു സർട്ടിഫിക്കറ്റിൽ പ്രവർത്തിക്കാം. ഹോസ്റ്റിലെ ഓരോ പുതുക്കലിനും പ്രതികരിക്കുന്നതിന് പകരം വംശത്തിന്റെ അടിസ്ഥാനത്തിൽ ഫിൽട്ടർ ചെയ്യുക. പൊതി സെർവറിന്റെ പ്രിവിലേജുകളോടെ പ്രവർത്തിക്കുന്ന വിന്യാസ കോഡാണ്, അതിനാൽ ആ സ്ഥാനത്തെ മറ്റേതൊരു സ്ക്രിപ്റ്റ് പോലെ അത് അവലോകനം ചെയ്യുക.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

അവതരിപ്പിച്ച ശൃംഖല ഫയലുമായി താരതമ്യം ചെയ്യുക

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

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