Hoe jo in VPN-kliïntkaai meitsje en in CSR foar ûndertekening yntsjinje

Earder of letter biedt in VPN-brûker oan om in priveekaai per e-mail te stjoeren sadat de behearder in sertifikaat meitsje kin, en krekt dat oanbod moat foarkommen wurde. De wurkjende stream hâldt de kaai fan it earste kommando ôf by de kliïnt: de kliïnt makket him, stjoert in sertifikaatûndertekeningsfersyk, de útjouwer kontrolearret en autorisearret it, en it ûndertekene sertifikaat komt werom om neist de kaai te stean dy't it makke hat. De checklist hjirûnder falt sletten by elke stap, en dat is it punt, want twa fan 'e fiif stappen binne krekt dyjinge dy't minsken oerslaan as se haast ha.

Stap 1: meitsje de kaai dêr't er libje sil

Meitsje op de masine dy't de kaai hâlde sil, en lit him dêr. In softwarekaai giet yn in bestân mei strange tastimmingen; in hardware-stipe kaai of in kaai yn in beheardwinkel wurdt nea in bestân, en syn ynskriuwpaad is meastentiids in apart ark ynstee fan in OpenSSL-kommando. Hoe dan ek, nimmen hoecht de priveehelte te sjen.

De softwarestream sjocht der sa út, mei de kaai en it fersyk yn ien sesje makke:

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"

De rigel umask is wichtiger as er liket. Sûnder him wurdt de kaai wrâldlêsber skreaun op in systeem dat standert tastiet, en it bestân letter omkopiearje ferspriedt dat. In besteande kaai opnij brûke is rjochtfeardige as er al beskerme is en by jo belied past; foar elk apparaat in nije meitsje is makliker te ûnderbouwen.

Stap 2: set de identiteit yn it fersyk, net yn 'e e-mail

Beslis wat de VPN eins autentisearret foar't it fersyk makke wurdt, want dat antwurd heart yn 'e CSR. OpenVPN keppelt fan âlds kliïntidentiteit oan 'e mienskiplike namme fan it sertifikaat, en ark lykas strongSwan lykje in identiteitstreng oan it ûnderwerp of in alternatyf ûnderwerpsnamme. In e-mail dy't seit dat myn namme alice is, is gjin bewiis, en in fersyk wêrfan it ûnderwerp itselde seit is mar in bytsje better.

Foegje in alternatyf ûnderwerpsnamme ta as jo kontrolearder ien kontrolearret, want moderne lykjen negearret faak it âlde CN:

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

Hâld it CN koart, stabyl en bûn oan it akkount ynstee fan oan in laptopmodel. In namme mei it searjenûmer fan it apparaat fan 'e brûker is in stipeprobleem dat wachtet op 'e earste hardwareferfanging.

Stap 3: kontrolearje it fersyk foar't jo it ûndertekenje

De útjouwer kontrolearret twa ferskillende dingen, en dy trocheinoar smite is de klassike flater. Earst, dat it fersyk yntern konsekwint is: de ûndertekening wurdt kontrolearre tsjin 'e iepenbiere kaai dy't it draacht. Twad, dat de oanfreegjer rjocht hat op wat it fersyk freget, en dêrop kin gjin kryptografyske kontrôle antwurdzje.

It meganyske part is ien kommando, en it soe in kontrôleresultaat tegearre mei it ûnderwerp printsje moatte:

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

Merk op wat dat bewiist. In fersyk dat kontrolearre wurdt, lit allinnich sjen dat de ôfstjoerder de byhearrende priveekaai op it tiidstip fan yntsjinjen hie; it bewiist net dat de ôfstjoerder de persoan is dy't yn it ûnderwerp neamd wurdt, en it autorisearret gjin tagong ta de groep of rûte dy't frege wurdt. Ynskriuwingsbeoardieling is in aparte poarte, en in fersyk foar in groep dy't nimmen goedkard hat moat ôfwiisd wurde ynstee fan stil bewurke te wurden.

Stap 4: autorisearje, en ûndertekenje dan mei eksplisite útwreidings

Ûndertekenjen is wêr't de CA belied beslút ynstee fan it fersyk letterlik oan te nimmen. Jildichheid, kaaiberik en de rolútwreiding hearre yn in útwreidingsbestân, net yn standertwearden dy't jo seis moannen letter net mear betinke. In kliïntsertifikaat foar VPN-autentikaasje hat kliïntautentikaasje as doel nedich.

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

Brûk -CAserial mei it besteande searjebestân as der al ien yn gebrûk is, en hâld de CA-kaai offline of yn it beskerme magazyn dat jo belied neamt. Sertifikaatsearjenûmers moatte unyk wêze per útjouwer; it searjebestân fan nul ôf opnij meitsje riskearret botsings dy't weromrop twifelich meitsje.

Registrearje wat útjûn is: searjenûmer, ûnderwerp, frege identiteit, goedkarrende persoan en ferfaldatum. Dat register is wêr't in weromropbeslissing letter op stipe, en it kin net allinnich út it sertifikaat weromboud wurde as it ynskriuwnspoar allinnich yn in postfak libbet.

Stap 5: ynstallearje it neist de byhearrende kaai en bewiis it pear

De kliïnt ûntfangt it sertifikaat en de keatling fan 'e útjouwer, nea in kaai. Befêstigje foar it ferbinen dat it sertifikaat echt pearret mei de kaai dy't al op skiif stiet, want in net oerienkommend pear jout folle letter in betiizjende hânskudflater:

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 twa gearfettings moatte oerienkomme. Ferbyn dan en befêstigje dat de identiteit dy't de server logt dejinge is dy't jo autorisearre hawwe, en net allinnich dat de tunnel omheech kaam. As de kaai ferlern giet of it apparaat ferfongen wurdt, is it antwurd weromrop plus in nij fersyk fan it nije apparaat; de behearder freegje om in kaai fan earne oars werom te stjoeren hellet it orizjineel net werom en brekt stil it model dat it fersyk feilich makke.