Paano gumawa ng key ng kliyenteng VPN at magsumite ng CSR para sa lagda

Maaga man o huli, may user ng VPN na mag-aalok na ipadala ang pribadong key sa email upang makagawa ang administrador ng sertipiko, at ang alok na iyon ang dapat tanggihan. Ang gumaganang daloy ay nagpapanatili ng key sa kliyente mula sa unang utos: ang kliyente ang gumagawa nito, nagpapadala ng kahilingan sa paglagda ng sertipiko, vine-verify at inaaproba ito ng naglalabas, at ang lagda na sertipiko ay bumabalik upang umupo sa tabi ng key na gumawa nito. Ang checklist sa ibaba ay nabigo nang sarado sa bawat hakbang, at iyon ang punto, dahil dalawa sa limang hakbang ang mismong nilalaktawan ng mga tao kapag nagmamadali sila.

Hakbang 1: gumawa ng key sa lugar kung saan ito maninirahan

Gumawa sa makina na mag-iingat ng key, at iwanan ito roon. Ang software key ay napupunta sa file na may mahigpit na pahintulot; ang key na sinusuportahan ng hardware o nasa pinamamahalaang imbakan ay hindi kailanman nagiging file, at ang landas ng pagpapatala nito ay karaniwang hiwalay na tool at hindi utos ng OpenSSL. Alinman sa dalawa, walang kailangang makakita ng pribadong kalahati.

Ang daloy ng software ay ganito, ang key at kahilingan ay ginawa sa isang sesyon:

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"

Ang linyang umask ay mas mahalaga kaysa sa itsura nito. Kung wala ito ang key ay isinusulat na nababasa ng lahat sa sistemang mapagpahintulot bilang default, at ang pagkopya ng file mamaya ay nagpapalaganap niyon. Ang muling paggamit ng umiiral na key ay lehitimo kapag protektado na ito at tumutugma sa iyong patakaran; ang paggawa ng bago sa bawat device ay mas madaling ipaliwanag.

Hakbang 2: ilagay ang pagkakakilanlan sa kahilingan, hindi sa email

Magpasya kung ano ang tunay na ine-authenticate ng VPN bago pa gawin ang kahilingan, dahil ang sagot na iyon ay kabilang sa loob ng CSR. OpenVPN tradisyonal na iniuugnay ang pagkakakilanlan ng kliyente sa karaniwang pangalan ng sertipiko, at ang mga tool tulad ng strongSwan ay nagtutugma ng string ng pagkakakilanlan sa paksa o alternatibong pangalan ng paksa. Ang email na nagsasabing ang pangalan ko ay alice ay hindi ebidensya, at ang kahilingang nagsasabi ng gayon din ang paksa ay medyo mas mabuti lamang.

Magdagdag ng alternatibong pangalan ng paksa kapag sinusuri ito ng iyong verifier, dahil kadalasang binabalewala ng modernong pagtutugma ang lumang CN:

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

Panatilihing maikli, matatag at nakatali sa account ang CN at hindi sa modelo ng laptop. Ang pangalan na naglalaman ng serial number ng device ng user ay problemang pang-suporta na naghihintay sa unang pagpapalit ng hardware.

Hakbang 3: i-verify ang kahilingan bago mo ito lagdaan

Dalawang magkaibang bagay ang vine-verify ng naglalabas, at ang paghahalo sa kanila ang klasikong pagkakamali. Una, na ang kahilingan ay panloob na magkakatugma: ang lagda ay vine-verify laban sa pampublikong key na dala nito. Ikalawa, na ang humihiling ay may karapatan sa hinihingi ng kahilingan, at hindi iyon masasagot ng anumang cryptographic na pagsusuri.

Ang mekanikal na bahagi ay isang utos, at dapat itong mag-print ng resulta ng pag-verify kasama ng paksa:

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

Pansinin kung ano ang pinapatunayan niyan. Ang kahilingang pumasa sa verify ay nagpapakita lamang na taglay ng nagpadala ang tugmang pribadong key sa oras ng pagsumite; hindi nito pinapatunayan na ang nagpadala ay ang taong pinangalanan sa paksa, at hindi nito pinapahintulutan ang pag-access sa grupo o ruta na hinihingi. Ang pagsusuri ng pagpapatala ay hiwalay na tarangkahan, at ang kahilingan para sa grupong walang nag-apruba ay dapat tanggihan sa halip na tahimik na i-edit.

Hakbang 4: magbigay ng pahintulot, pagkatapos ay pumirma gamit ang tahasang mga extension

Ang paglagda ang lugar kung saan nagpapasya ang CA ng patakaran sa halip na tanggapin ang kahilingan nang literal. Ang bisa, paggamit ng key at extension ng tungkulin ay kabilang sa file ng extension, hindi sa mga default na hindi mo maaalala pagkalipas ng anim na buwan. Ang sertipiko ng kliyente para sa authentication ng VPN ay nangangailangan ng authentication ng kliyente bilang layunin nito.

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

Gamitin ang -CAserial kasama ang umiiral na serial file kung may ginagamit na, at panatilihing offline ang CA key o sa protektadong imbakan na pinangalanan ng iyong patakaran. Ang mga serial number ng sertipiko ay dapat natatangi sa bawat naglalabas; ang muling paggawa ng serial file mula sa simula ay nanganganib ng mga banggaan na nagpapaging malabo ang pagbawi.

Itala kung ano ang inilabas: serial number, paksa, hiniling na pagkakakilanlan, taong nag-apruba at pag-expire. Ang talaang iyon ang pinagbabatayan ng desisyon sa pagbawi mamaya, at hindi ito maaaring muling buuin mula sa sertipiko lamang kung ang bakas ng pagpapatala ay nabubuhay lamang sa isang mailbox.

Hakbang 5: i-install ito sa tabi ng tugmang key at patunayan ang pares

Natatanggap ng kliyente ang sertipiko at ang chain ng naglalabas, hindi kailanman key. Bago kumonekta, kumpirmahin na ang sertipiko ay talagang nagpapares sa key na nasa disk na, dahil ang pares na hindi tugma ay gumagawa ng nakakalitong pagkabigo sa handshake na malayo pa ang hinaharap:

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

Dapat magtugma ang dalawang digest. Pagkatapos kumonekta at kumpirmahin na ang pagkakakilanlang itinatala ng server ay ang pinahintulutan mo, at hindi lamang na umangat ang tunnel. Kung mawala ang key o mapalitan ang device, ang sagot ay pagbawi kasama ang bagong kahilingan mula sa bagong device; ang paghingi sa administrador na ibalik ang key mula sa ibang lugar ay hindi nagbabalik ng orihinal at tahimik na sinisira ang modelong nagpaging ligtas sa kahilingan.