Sådan genererer du en VPN-klientnøgle og sender en CSR til signering

Før eller siden tilbyder en VPN-bruger at sende en privat nøgle med e-mail, så administratoren kan lave et certifikat, og det tilbud er netop det, man skal afvise. Det flow, der virker, holder nøglen på klienten fra den første kommando: klienten genererer den, sender en anmodning om certifikatsignering, udstederen bekræfter og godkender den, og det signerede certifikat kommer tilbage og ligger ved siden af den nøgle, der skabte det. Tjeklisten nedenfor fejler lukket ved hvert trin, og det er pointen, fordi to af de fem trin er dem, folk springer over, når de har travlt.

Trin 1: generer nøglen, hvor den skal bo

Generer på den maskine, der skal have nøglen, og behold den der. En softwarenøgle ender i en fil med stramme tilladelser; en hardwareunderstøttet nøgle eller en nøgle i et administreret lager bliver aldrig en fil, og dens tilmeldingsvej er normalt et separat værktøj frem for en OpenSSL-kommando. Uanset hvad, behøver ingen at se den private halvdel.

Softwareflowet ser sådan ud, hvor nøglen og anmodningen oprettes i én session:

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 betyder mere, end den ser ud til. Uden den skrives nøglen læsbar for alle på et system med standardtilladelser, og at kopiere filen rundt senere spreder det. Genbrug af en eksisterende nøgle er legitimt, når den allerede er beskyttet og passer til din politik; at generere en ny til hver enhed er lettere at begrunde.

Trin 2: læg identiteten i anmodningen, ikke i e-mailen

Beslut, hvad VPN faktisk autentificerer, før anmodningen oprettes, fordi det svar hører inde i CSR'en. OpenVPN knytter traditionelt klientidentitet til certifikatets fælles navn, og værktøjer som strongSwan matcher en identitetsstreng mod subjektet eller et alternativt subjektnavn. En e-mail, der siger, at jeg hedder alice, er ikke bevis, og en anmodning, hvis subjekt siger det samme, er kun lidt bedre.

Tilføj et alternativt subjektnavn, når din verifierer tjekker et, da moderne matchning 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 frem for til en bærbarmodel. Et navn, der indeholder brugerens enhedsserienummer, er et supportproblem, der venter på den første hardwareudskiftning.

Trin 3: bekræft anmodningen, før du signerer den

Udstederen bekræfter to forskellige ting, og at blande dem sammen er den klassiske fejl. For det første, at anmodningen er internt konsistent: signaturen bekræftes mod den offentlige nøgle, den bærer. For det andet, at ansøgeren har ret til det, anmodningen beder om, og det kan ingen kryptografisk kontrol svare på.

Den mekaniske del er én kommando, og den bør udskrive et bekræftelsesresultat sammen med subjektet:

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

Bemærk, hvad det beviser. En anmodning, der bekræftes, viser kun, at afsenderen havde den matchende private nøgle på afsendelsestidspunktet; den beviser ikke, at afsenderen er den person, der er nævnt i subjektet, og den godkender ikke den gruppe- eller ruteadgang, der anmodes om. Tilmeldingsgennemgang er en separat port, og en anmodning om en gruppe, som ingen har godkendt, bør afvises frem for stille at blive redigeret.

Trin 4: godkend, og signer derefter med eksplicitte udvidelser

Signering er der, hvor CA'en beslutter politik i stedet for at acceptere anmodningen ordret. Gyldighed, nøglebrug og rolleudvidelsen hører i en udvidelsesfil, ikke i standardværdier, du ikke kan huske seks måneder senere. Et klientcertifikat til VPN-autentificering har brug for klientautentificering som sit 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

Brug -CAserial med den eksisterende serienummerfil, hvis en allerede er i brug, og hold CA-nøglen offline eller i det beskyttede lager, din politik angiver. Certifikaters serienumre skal være unikke for hver udsteder; at genskabe serienummerfilen fra bunden risikerer kollisioner, der gør tilbagekaldelse tvetydig.

Registrer, hvad der blev udstedt: serienummer, subjekt, anmodet identitet, godkendende person og udløb. Den registrering er det, en tilbagekaldelsesbeslutning senere afhænger af, og den kan ikke genopbygges alene ud fra certifikatet, hvis tilmeldingssporet kun lever i en postkasse.

Trin 5: installer det ved siden af den matchende nøgle, og bevis parringen

Klienten modtager certifikatet og udstederkæden, aldrig en nøgle. Før du forbinder, skal du bekræfte, at certifikatet faktisk parrer med den nøgle, der allerede ligger på disken, fordi et ikke-matchende par giver en forvirrende håndtryksfejl meget 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 digests skal matche. Forbind derefter, og bekræft, at den identitet, serveren logger, er den, du godkendte, og ikke blot at tunnelen kom op. Hvis nøglen mistes, eller enheden udskiftes, er svaret tilbagekaldelse plus en ny anmodning fra den nye enhed; at bede administratoren om at sende en nøgle tilbage fra et andet sted gendanner ikke originalen og bryder stille den model, der gjorde anmodningen sikker.