Slik genererer du en VPN-klientnøkkel og sender en CSR til signering

Før eller siden tilbyr en VPN-bruker å sende en privat nøkkel på e-post slik at administratoren kan lage et sertifikat, og nettopp det tilbudet er det man skal avvise. Flyten som fungerer holder nøkkelen på klienten fra den første kommandoen: klienten genererer den, sender en forespørsel om sertifikatsignering, utstederen verifiserer og autoriserer den, og det signerte sertifikatet kommer tilbake og ligger ved siden av nøkkelen som skapte det. Sjekklisten nedenfor feiler lukket ved hvert trinn, og det er poenget, fordi to av de fem trinnene er nettopp dem folk hopper over når de har det travelt.

Trinn 1: generer nøkkelen der den skal bo

Generer på maskinen som skal holde nøkkelen, og la den ligge der. En programvarenøkkel havner i en fil med strenge tillatelser; en maskinvarebasert nøkkel eller en nøkkel i et administrert lager blir aldri en fil, og registreringsveien er vanligvis et eget verktøy og ikke en OpenSSL-kommando. Uansett trenger ingen å se den private halvdelen.

Programvareflyten ser slik ut, med nøkkelen og forespørselen laget i én ø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"

Linjen umask betyr mer enn den ser ut til. Uten den skrives nøkkelen lesbar for alle på et system som er tillatende som standard, og å kopiere filen rundt senere sprer det. Å gjenbruke en eksisterende nøkkel er legitimt når den allerede er beskyttet og passer med policyen din; å generere en ny per enhet er lettere å begrunne.

Trinn 2: sett identiteten i forespørselen, ikke i e-posten

Bestem hva VPN-en faktisk autentiserer før forespørselen lages, fordi det svaret hører hjemme inne i CSR-en. OpenVPN knytter tradisjonelt klientidentitet til sertifikatets fellesnavn, og verktøy som strongSwan matcher en identitetsstreng mot subjektet eller et alternativt subjektnavn. En e-post som sier at jeg heter alice er ikke bevis, og en forespørsel der subjektet sier det samme er bare litt bedre.

Legg til et alternativt subjektnavn når verifisereren din sjekker et, siden 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"

Hold CN kort, stabilt og knyttet til kontoen i stedet for til en bærbarmodell. Et navn som inneholder serienummeret til brukerens enhet er et støtteproblem som venter på den første maskinvareutskiftningen.

Trinn 3: verifiser forespørselen før du signerer den

Utstederen verifiserer to forskjellige ting, og å blande dem er den klassiske feilen. For det første at forespørselen er internt konsistent: signaturen verifiseres mot den offentlige nøkkelen den bærer. For det andre at forespørgeren har rett til det forespørselen ber om, og det kan ingen kryptografisk kontroll svare på.

Den mekaniske delen er én kommando, og den bør skrive ut et verifiseringsresultat sammen 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 hva det beviser. En forespørsel som verifiseres viser bare at avsenderen hadde den samsvarende private nøkkelen ved innsendingstidspunktet; den beviser ikke at avsenderen er personen som er navngitt i subjektet, og den autoriserer ikke gruppe- eller ruteadgangen som bes om. Registreringsgjennomgang er en egen port, og en forespørsel om en gruppe ingen har godkjent bør avvises i stedet for å redigeres i stillhet.

Trinn 4: autoriser, og signer deretter med eksplisitte utvidelser

Signering er der CA-en bestemmer policy i stedet for å akseptere forespørselen ordrett. Gyldighet, nøkkelbruk og rolleutvidelsen hører i en utvidelsesfil, ikke i standardverdier du ikke husker seks måneder senere. Et klientsertifikat for VPN-autentisering trenger klientautentisering som formå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 eksisterende serienummerfilen hvis en allerede er i bruk, og hold CA-nøkkelen offline eller i det beskyttede lageret policyen din navngir. Sertifikaters serienumre må være unike per utsteder; å gjenopprette serienummerfilen fra bunnen av risikerer kollisjoner som gjør tilbakekalling tvetydig.

Registrer hva som ble utstedt: serienummer, subjekt, forespurt identitet, godkjennende person og utløp. Den registreringen er det en tilbakekallingsbeslutning senere avhenger av, og den kan ikke gjenoppbygges bare fra sertifikatet hvis registreringssporet bare lever i en postkasse.

Trinn 5: installer det ved siden av den samsvarende nøkkelen og bevis paret

Klienten mottar sertifikatet og utstederkjeden, aldri en nøkkel. Før du kobler til, bekreft at sertifikatet faktisk parer med nøkkelen som allerede ligger på disken, fordi et par som ikke samsvarer gir en forvirrende håndtrykkfeil mye senere:

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

De to digestene må samsvare. Koble deretter til og bekreft at identiteten serveren logger er den du autoriserte, og ikke bare at tunnelen kom opp. Hvis nøkkelen mistes eller enheten byttes, er svaret tilbakekalling pluss en ny forespørsel fra den nye enheten; å be administratoren sende tilbake en nøkkel fra et annet sted gjenoppretter ikke originalen og bryter i stillhet modellen som gjorde forespørselen trygg.