VPN ക്ലയന്റ് കീ എങ്ങനെ സൃഷ്ടിക്കാം, ഒപ്പിടാൻ CSR എങ്ങനെ സമർപ്പിക്കാം

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

ഘട്ടം 1: കീ ജീവിക്കുന്ന ഇടത്തുതന്നെ അത് സൃഷ്ടിക്കുക

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

സോഫ്റ്റ്വെയർ പ്രവാഹം ഇങ്ങനെയാണ്, കീയും അഭ്യർത്ഥനയും ഒരേ സെഷനിൽ സൃഷ്ടിക്കുന്നു:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

ഘട്ടം 2: ഐഡന്റിറ്റി അഭ്യർത്ഥനയിൽ വയ്ക്കുക, ഇമെയിലിൽ അല്ല

അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നതിന് മുമ്പ് VPN യഥാർത്ഥത്തിൽ എന്താണ് പ്രാമാണീകരിക്കുന്നതെന്ന് തീരുമാനിക്കുക, കാരണം ആ ഉത്തരം CSR-നുള്ളിൽ ഉള്ളതാണ്. OpenVPN പരമ്പരാഗതമായി ക്ലയന്റ് ഐഡന്റിറ്റിയെ സർട്ടിഫിക്കറ്റിന്റെ പൊതു നാമവുമായി ബന്ധിപ്പിക്കുന്നു, strongSwan പോലുള്ള ഉപകരണങ്ങൾ ഐഡന്റിറ്റി സ്ട്രിംഗ് വിഷയവുമായോ വിഷയത്തിന്റെ ഇതര നാമവുമായോ ചേർത്ത് നോക്കുന്നു. എന്റെ പേര് alice എന്ന് പറയുന്ന ഇമെയിൽ തെളിവല്ല, വിഷയം അതേ കാര്യം പറയുന്ന അഭ്യർത്ഥന അല്പം മാത്രം മെച്ചമാണ്.

നിങ്ങളുടെ പരിശോധകൻ ഒന്ന് പരിശോധിക്കുമ്പോൾ വിഷയത്തിന്റെ ഇതര നാമം ചേർക്കുക, കാരണം ആധുനിക പൊരുത്തം പഴയ CN പലപ്പോഴും അവഗണിക്കുന്നു:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ചെറുതും സ്ഥിരവുമായി സൂക്ഷിക്കുക, ലാപ്ടോപ്പ് മോഡലിന് പകരം അക്കൗണ്ടുമായി ബന്ധിപ്പിക്കുക. ഉപയോക്താവിന്റെ ഉപകരണത്തിന്റെ സീരിയൽ നമ്പർ അടങ്ങിയ പേര് ആദ്യ ഹാർഡ്വെയർ മാറ്റത്തിനായി കാത്തിരിക്കുന്ന പിന്തുണാ പ്രശ്നമാണ്.

ഘട്ടം 3: ഒപ്പിടുന്നതിന് മുമ്പ് അഭ്യർത്ഥന പരിശോധിക്കുക

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

യാന്ത്രിക ഭാഗം ഒരു കമാൻഡാണ്, അത് വിഷയത്തോടൊപ്പം പരിശോധനാ ഫലം പ്രിന്റ് ചെയ്യണം:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

ഘട്ടം 4: അധികാരപ്പെടുത്തുക, പിന്നീട് വ്യക്തമായ എക്സ്റ്റൻഷനുകളോടെ ഒപ്പിടുക

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

ഇതിനകം ഒന്ന് ഉപയോഗത്തിലുണ്ടെങ്കിൽ നിലവിലുള്ള സീരിയൽ ഫയലിനൊപ്പം -CAserial ഉപയോഗിക്കുക, ഒപ്പം CA കീ ഓഫ്ലൈനായോ നിങ്ങളുടെ നയം പേരിടുന്ന സംരക്ഷിത സ്റ്റോറിലോ സൂക്ഷിക്കുക. സർട്ടിഫിക്കറ്റ് സീരിയൽ നമ്പറുകൾ ഓരോ ഇഷ്യൂവർക്കും അദ്വിതീയമായിരിക്കണം; സീരിയൽ ഫയൽ പൂജ്യത്തിൽ നിന്ന് പുനഃസൃഷ്ടിക്കുന്നത് റദ്ദാക്കൽ അവ്യക്തമാക്കുന്ന കൂട്ടിയിടികൾക്ക് സാദ്ധ്യതയുണ്ട്.

എന്താണ് ഇഷ്യൂ ചെയ്തതെന്ന് രേഖപ്പെടുത്തുക: സീരിയൽ, വിഷയം, ആവശ്യപ്പെട്ട ഐഡന്റിറ്റി, അംഗീകരിച്ച വ്യക്തി, കാലാവധി. ആ രേഖയാണ് പിന്നീട് റദ്ദാക്കൽ തീരുമാനം ആശ്രയിക്കുന്നത്, രജിസ്ട്രേഷന്റെ അടയാളം ഒരു തപാൽപ്പെട്ടിയിൽ മാത്രം ജീവിക്കുന്നെങ്കിൽ സർട്ടിഫിക്കറ്റിൽ നിന്ന് മാത്രം അത് പുനർനിർമ്മിക്കാനാവില്ല.

ഘട്ടം 5: യോജിക്കുന്ന കീയുടെ അരികിൽ അത് ഇൻസ്റ്റാൾ ചെയ്ത് ജോടി തെളിയിക്കുക

ക്ലയന്റിന് ലഭിക്കുന്നത് സർട്ടിഫിക്കറ്റും ഇഷ്യൂവറുടെ ശൃംഖലയുമാണ്, ഒരിക്കലും കീയല്ല. കണക്ട് ചെയ്യുന്നതിന് മുമ്പ്, സർട്ടിഫിക്കറ്റ് ഡിസ്കിൽ ഇതിനകം ഉള്ള കീയുമായി യഥാർത്ഥത്തിൽ ജോടിയാകുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക, കാരണം യോജിക്കാത്ത ജോടി വളരെ വൈകി ആശയക്കുഴപ്പമുള്ള ഹാൻഡ്ഷേക്ക് പരാജയം ഉണ്ടാക്കുന്നു:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

രണ്ട് ഡൈജസ്റ്റുകളും യോജിക്കണം. തുടർന്ന് കണക്ട് ചെയ്ത്, സർവർ രേഖപ്പെടുത്തുന്ന ഐഡന്റിറ്റി നിങ്ങൾ അധികാരപ്പെടുത്തിയതാണെന്ന് സ്ഥിരീകരിക്കുക, ടണൽ ഉയർന്നു എന്ന് മാത്രമല്ല. കീ നഷ്ടപ്പെടുകയോ ഉപകരണം മാറ്റുകയോ ചെയ്താൽ ഉത്തരം റദ്ദാക്കലും പുതിയ ഉപകരണത്തിൽ നിന്നുള്ള പുതിയ അഭ്യർത്ഥനയുമാണ്; അഡ്മിനിസ്ട്രേറ്ററോട് മറ്റെവിടെ നിന്നോ കീ തിരികെ അയയ്ക്കാൻ ആവശ്യപ്പെടുന്നത് യഥാർത്ഥത്തെ തിരികെ കൊണ്ടുവരുന്നില്ല, അഭ്യർത്ഥന സുരക്ഷിതമാക്കിയ മാതൃക നിശബ്ദമായി തകർക്കുന്നു.