Hoe om 'n VPN-kliëntsleutel te genereer en 'n CSR vir ondertekening in te dien

Vroeër of later bied 'n VPN-gebruiker aan om 'n private sleutel per e-pos te stuur sodat die administrateur 'n sertifikaat kan maak, en dit is juis daardie aanbod wat 'n mens moet weier. Die werkbare vloei hou die sleutel vanaf die eerste opdrag op die kliënt: die kliënt skep dit, stuur 'n sertifikaatondertekeningsversoek, die uitreiker verifieer en magtig dit, en die ondertekende sertifikaat kom terug om langs die sleutel te lê wat dit geskep het. Die kontrolelys hieronder faal geslote by elke stap, en dit is die punt, want twee van die vyf stappe is diegene wat mense oorslaan wanneer hulle haastig is.

Stap 1: skep die sleutel waar dit sal woon

Genereer op die masjien wat die sleutel gaan hou, en hou dit daar. 'n Sagteware-sleutel beland in 'n lêer met streng beperkings; 'n sleutel wat deur hardeware gesteun of in 'n bestuurde stoor gehou word, word nooit 'n lêer nie, en die inskrywingspad daarvan is gewoonlik 'n aparte gereedskap eerder as 'n OpenSSL-opdrag. Hoe dit ook al sy, niemand hoef die private helfte te sien nie.

Die sagteware-vloei lyk so, met die sleutel en die versoek in een sessie geskep:

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"

Die lyn umask maak meer saak as wat dit lyk. Sonder dit word die sleutel wêreldleesbaar geskryf op 'n stelsel wat standaard toelatend is, en om die lêer later rond te kopieer versprei dit. Om 'n bestaande sleutel te hergebruik is regmatig wanneer dit reeds beskerm is en by jou beleid pas; om per toestel 'n nuwe een te skep is makliker om te beredeneer.

Stap 2: sit die identiteit in die versoek, nie in die e-pos nie

Besluit wat die VPN werklik verifieer voordat die versoek geskep word, want daardie antwoord hoort binne die CSR. OpenVPN baseer tradisioneel kliëntidentiteit op die sertifikaat se algemene naam, en gereedskap soos strongSwan pas 'n identiteitsstring teen die onderwerp of 'n onderwerp-alternatiewe naam. 'n E-pos wat sê my naam is alice is nie bewyse nie, en 'n versoek waarvan die onderwerp dieselfde sê is net effens beter.

Voeg 'n onderwerp-alternatiewe naam by wanneer jou verifieerder een nagaan, want moderne passing ignoreer dikwels die ou CN:

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

Hou die CN kort, stabiel en gebind aan die rekening eerder as aan 'n skootrekenaarmodel. 'n Naam wat die gebruikerstoestel se reeksnommer bevat, is 'n ondersteuningsprobleem wat wag op die eerste hardewarevervanging.

Stap 3: verifieer die versoek voordat jy dit onderteken

Die uitreiker verifieer twee verskillende dinge, en om dit te verwar is die klassieke fout. Eerstens, dat die versoek intern konsekwent is: die handtekening verifieer teen die publieke sleutel wat dit dra. Tweedens, dat die versoeker geregtig is op wat die versoek vra, wat geen kriptografiese kontrole kan antwoord nie.

Die meganiese deel is een opdrag, en dit behoort 'n verifikasie-uitslag saam met die onderwerp te druk:

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

Let op wat dit bewys. 'n Versoek wat verifieer wys net dat die sender die ooreenstemmende private sleutel op indieningstyd gehad het; dit bewys nie dat die sender die persoon is wat in die onderwerp genoem word nie, en dit magtig nie die groep- of roetetoegang wat aangevra word nie. Inskrywingshersiening is 'n aparte hek, en 'n versoek wat 'n groep vra wat niemand goedgekeur het nie, moet verwerp word eerder as om dit stilweg te redigeer.

Stap 4: magtig, en onderteken dan met eksplisiete uitbreidings

Ondertekening is waar die CA beleid besluit eerder as om die versoek woordeliks te aanvaar. Geldigheid, sleutelgebruik en die roluitbreiding hoort in 'n uitbreidingslêer, nie in verstekke wat jy ses maande later nie kan onthou nie. 'n Kliëntsertifikaat vir VPN-verifikasie het kliëntverifikasie as sy doel nodig.

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

Gebruik -CAserial met die bestaande reekslêer as een reeds in gebruik is, en hou die CA-sleutel vanlyn of in watter beskermde stoor jou beleid ook al noem. Sertifikaatreeksnommers moet uniek per uitreiker wees; om die reekslêer van nuuts af te herskep waag botsings wat herroeping dubbelsinnig maak.

Teken aan wat uitgereik is: reeksnommer, onderwerp, versoekte identiteit, goedkeurende persoon en vervaldatum. Daardie rekord is waarop 'n herroepingsbesluit later staatmaak, en dit kan nie net uit die sertifikaat herbou word as die inskrywingspoor net in 'n posbus leef nie.

Stap 5: installeer dit langs die ooreenstemmende sleutel en bewys die paring

Die kliënt ontvang die sertifikaat en die uitreikerketting, nooit 'n sleutel nie. Voordat jy koppel, bevestig dat die sertifikaat werklik met die sleutel wat reeds op skyf is, paar, want 'n bypassende paar lewer baie later 'n verwarrende handskuddingsfout:

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

Die twee samevattings moet ooreenstem. Koppel dan en bevestig dat die identiteit wat die bediener log die een is wat jy gemagtig het, nie bloot dat die tonnel opgekom het nie. As die sleutel verlore is of die toestel vervang word, is die antwoord herroeping plus 'n nuwe versoek van die nuwe toestel; om die administrateur te vra om 'n sleutel van elders terug te stuur herstel nie die oorspronklike nie en breek stilweg die model wat die versoek veilig gemaak het.