Korleis generere ein VPN-klientnøkkel og sende ein CSR til signering

Før eller sidan tilbyr ein VPN-brukar å sende ein privat nøkkel på e-post slik at administratoren kan lage eit sertifikat, og nettopp det tilbodet er det ein skal avvise. Flyten som fungerer held nøkkelen på klienten frå den første kommandoen: klienten genererer han, sender ein førespurnad om sertifikatsignering, utferdaren stadfester og autoriserer han, og det signerte sertifikatet kjem tilbake og ligg ved sida av nøkkelen som skapte det. Sjekklista nedanfor feilar lukka ved kvart steg, og det er poenget, fordi to av dei fem stega er nettopp dei folk hoppar over når dei har det travelt.

Steg 1: generer nøkkelen der han skal bu

Generer på maskinen som skal halde nøkkelen, og lat han liggje der. Ein programvarenøkkel hamnar i ei fil med strenge løyve; ein maskinvarebasert nøkkel eller ein nøkkel i eit administrert lager blir aldri ei fil, og registreringsvegen er vanlegvis eit eige verktøy og ikkje ein OpenSSL-kommando. Uansett treng ingen å sjå den private halvdelen.

Programvareflyten ser slik ut, med nøkkelen og førespurnaden laga i éi økt:

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"

Lina umask tyder meir enn ho ser ut til. Utan henne blir nøkkelen skriven lesbar for alle på eit system som er tillatande som standard, og å kopiere fila rundt seinare spreier det. Å bruke ein eksisterande nøkkel på nytt er legitimt når han alt er verna og passar med policyen din; å generere ein ny per eining er lettare å grunngi.

Steg 2: set identiteten i førespurnaden, ikkje i e-posten

Avgjer kva VPN-en faktisk autentiserer før førespurnaden blir laga, fordi det svaret høyrer heime inne i CSR-en. OpenVPN knyter tradisjonelt klientidentitet til fellesnamnet på sertifikatet, og verktøy som strongSwan matchar ein identitetsstreng mot subjektet eller eit alternativt subjektnamn. Ein e-post som seier at eg heiter alice er ikkje bevis, og ein førespurnad der subjektet seier det same er berre litt betre.

Legg til eit alternativt subjektnamn når stadfestaren din sjekkar eitt, sidan moderne matching ofte ignorerer det gamle CN:

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

Hald CN kort, stabilt og knytt til kontoen i staden for til ein berbar modell. Eit namn som inneheld serienummeret til eininga til brukaren er eit støtteproblem som ventar på den første maskinvareutskiftinga.

Steg 3: stadfest førespurnaden før du signerer han

Utferdaren stadfester to ulike ting, og å blande dei er den klassiske feilen. For det første at førespurnaden er internt konsistent: signaturen blir stadfesta mot den offentlege nøkkelen han ber. For det andre at førespøraren har rett til det førespurnaden ber om, og det kan ingen kryptografisk kontroll svare på.

Den mekaniske delen er éin kommando, og han bør skrive ut eit stadfestingsresultat saman med subjektet:

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

Legg merke til kva det beviser. Ein førespurnad som blir stadfesta viser berre at avsendaren hadde den samsvarande private nøkkelen ved innsendingstidspunktet; han beviser ikkje at avsendaren er personen som er nemnd i subjektet, og han autoriserer ikkje gruppe- eller ruteåtkomsten som blir beden om. Registreringsgjennomgang er ei eiga port, og ein førespurnad om ei gruppe ingen har godkjent bør avvisast i staden for å bli redigert i stillheit.

Steg 4: autoriser, og signer deretter med eksplisitte utvidingar

Signering er der CA-en avgjer policy i staden for å godta førespurnaden ordrett. Gyldigheit, nøkkelbruk og rolleutvidinga høyrer i ei utvidingsfil, ikkje i standardverdiar du ikkje hugsar seks månader seinare. Eit klientsertifikat for VPN-autentisering treng klientautentisering som føremål.

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

Bruk -CAserial med den eksisterande serienummerfila viss ei alt er i bruk, og hald CA-nøkkelen offline eller i det verna lageret policyen din nemner. Serienummer på sertifikat må vere unike per utferdar; å gjenopprette serienummerfila frå botnen risikerer kollisjonar som gjer tilbakekalling tvitydig.

Registrer kva som vart utferda: serienummer, subjekt, førespurad identitet, godkjennande person og utløp. Den registreringa er det ei tilbakekallingsavgjerd seinare er avhengig av, og ho kan ikkje byggjast opp att berre frå sertifikatet viss registreringssporet berre lever i ein postkasse.

Steg 5: installer det ved sida av den samsvarande nøkkelen og prov paret

Klienten mottek sertifikatet og utferdarkjeda, aldri ein nøkkel. Før du koplar til, stadfest at sertifikatet faktisk parar med nøkkelen som alt ligg på disken, fordi eit par som ikkje samsvarar gir ein forvirrande handtrykkfeil mykje seinare:

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

Dei to digestane må samsvare. Kopla deretter til og stadfest at identiteten serveren loggar er den du autoriserte, og ikkje berre at tunnelen kom opp. Viss nøkkelen blir borte eller eininga blir bytt, er svaret tilbakekalling pluss ein ny førespurnad frå den nye eininga; å be administratoren sende tilbake ein nøkkel frå ein annan stad gjenopprettar ikkje originalen og bryt i stillheit modellen som gjorde førespurnaden trygg.