Kuidas luua VPN-kliendi võti ja esitada CSR allkirjastamiseks

Varem või hiljem pakub VPN-i kasutaja saata privaatvõtme e-postiga, et administraator saaks sertifikaadi teha, ja just see pakkumine tuleb tagasi lükata. Toimiv voog hoiab võtit kliendi juures alates esimesest käsust: klient genereerib selle, saadab sertifikaadi allkirjastamise taotluse, väljaandja kontrollib ja volitab selle ning allkirjastatud sertifikaat tuleb tagasi ja seisab selle võtme kõrval, mis selle lõi. Allpool olev kontroll-loend ebaõnnestub iga sammu juures suletult ja see ongi mõte, sest kaks viiest sammust on just need, mille inimesed kiirustades vahele jätavad.

Samm 1: genereerige võti seal, kus see elab

Genereerige masinas, mis võtit hoiab, ja jätke see sinna. Tarkvaravõti läheb faili, millel on ranged õigused; riistvaraga toetatud või hallatavas hoidlas olev võti ei muutu kunagi failiks ja selle registreerimise tee on tavaliselt eraldi tööriist, mitte OpenSSL-i käsk. Ükskõik kuidas, keegi ei pea nägema privaatset poolt.

Tarkvaravoog näeb välja selline, kus võti ja taotlus luuakse ühes seansis:

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"

Rida umask on tähtsam, kui tundub. Ilma selleta kirjutatakse võti vaikimisi lubavas süsteemis kõigile loetavana ja faili hilisem kopeerimine levitab seda. Olemasoleva võtme taaskasutamine on õigustatud, kui see on juba kaitstud ja vastab teie poliitikale; iga seadme jaoks uue genereerimine on lihtsamini põhjendatav.

Samm 2: pange identiteet taotlusse, mitte e-kirja

Otsustage, mida VPN tegelikult autentib, enne kui taotlus luuakse, sest see vastus kuulub CSR-i sisse. OpenVPN seob kliendi identiteedi traditsiooniliselt sertifikaadi üldnimega ja tööriistad nagu strongSwan sobitavad identiteedistringi subjektiga või subjekti alternatiivse nimega. E-kiri, mis ütleb, et minu nimi on alice, ei ole tõend, ja taotlus, mille subjekt ütleb sama, on ainult pisut parem.

Lisage subjekti alternatiivne nimi, kui teie kontrollija seda kontrollib, kuna kaasaegne sobitamine eirab sageli vana CN-i:

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

Hoidke CN lühike, stabiilne ja seotud kontoga, mitte sülearvuti mudeliga. Nimi, mis sisaldab kasutaja seadme seerianumbrit, on tugiprobleem, mis ootab esimest riistvara vahetust.

Samm 3: kontrollige taotlust enne selle allkirjastamist

Väljaandja kontrollib kahte erinevat asja ja nende segamine on klassikaline viga. Esiteks, et taotlus on sisemiselt kooskõlas: allkiri kontrollitakse selle kantava avaliku võtme vastu. Teiseks, et taotlejal on õigus sellele, mida taotlus palub, ja sellele ei suuda ükski krüptograafiline kontroll vastata.

Mehaaniline osa on üks käsk ja see peaks välja printima kontrollitulemuse koos subjektiga:

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

Pange tähele, mida see tõestab. Kontrolli läbiv taotlus näitab ainult seda, et saatjal oli esitamise hetkel vastav privaatvõti; see ei tõesta, et saatja on subjektis nimetatud isik, ega volita taotletavat grupi- või marsruudijuurdepääsu. Registreerimise ülevaatus on eraldi värav ja taotlus grupile, mida keegi ei kinnitanud, tuleks tagasi lükata, mitte vaikselt ümber kirjutada.

Samm 4: volitage ja seejärel allkirjastage selgete laiendustega

Allkirjastamine on koht, kus CA otsustab poliitika, selle asemel et taotlus sõna-sõnalt vastu võtta. Kehtivus, võtme kasutamine ja rollilaiend kuuluvad laiendusfaili, mitte vaikeväärtustesse, mida te kuue kuu pärast ei mäleta. VPN-i autentimise kliendisertifikaat vajab oma otstarbeks kliendi autentimist.

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

Kasutage -CAserial olemasoleva seerianumbrifailiga, kui üks on juba kasutusel, ja hoidke CA võtit võrguühenduseta või mis tahes kaitstud hoidlas, mille teie poliitika nimetab. Sertifikaatide seerianumbrid peavad olema iga väljaandja jaoks unikaalsed; seerianumbrifaili nullist uuesti loomine riskib kokkupõrgetega, mis muudavad tühistamise mitmetähenduslikuks.

Registreerige, mis väljastati: seerianumber, subjekt, taotletud identiteet, kinnitaja ja aegumine. Just see kirje on see, millele tühistamisotsus hiljem toetub, ja seda ei saa ainult sertifikaadist taastada, kui registreerimise jälg elab ainult postkastis.

Samm 5: paigaldage see sobiva võtme kõrvale ja tõestage paar

Klient saab sertifikaadi ja väljaandja ahela, mitte kunagi võtme. Enne ühendamist kinnitage, et sertifikaat tõesti moodustab paari kettal juba oleva võtmega, sest sobimatu paar tekitab palju hiljem segadust tekitava käepigistuse tõrke:

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

Kaks lühendit peavad kattuma. Seejärel ühenduge ja kinnitage, et identiteet, mille server logib, on see, mille te volitasite, mitte lihtsalt see, et tunnel tõusis. Kui võti kaob või seade vahetatakse, on vastus tühistamine pluss uus taotlus uuest seadmest; administraatorilt mujalt võtme tagasisaatmise palumine ei taasta originaali ja lammutab vaikselt mudeli, mis tegi taotluse turvaliseks.