VPN-asiakasavaimen luominen ja CSR:n lähettäminen allekirjoitettavaksi

Ennemmin tai myöhemmin VPN-käyttäjä tarjoutuu lähettämään yksityisen avaimen sähköpostitse, jotta ylläpitäjä voi tehdä varmenteen, ja juuri se tarjous pitää torjua. Toimiva kulku pitää avaimen asiakkaalla ensimmäisestä komennosta: asiakas luo sen, lähettää varmenteen allekirjoituspyynnön, myöntäjä vahvistaa ja valtuuttaa sen, ja allekirjoitettu varmenne palaa seisomaan sen avaimen vieressä, joka sen loi. Alla oleva tarkistuslista epäonnistuu suljetusti joka vaiheessa, ja se on tarkoitus, koska kaksi viidestä vaiheesta ovat juuri niitä, jotka ihmiset jättävät väliin kiirehtiessään.

Vaihe 1: luo avain sinne, missä se tulee elämään

Luo se koneella, joka tulee pitämään avainta, ja jätä se sinne. Ohjelmistoavain päätyy tiedostoon, jolla on tiukat käyttöoikeudet; laitteistopohjainen avain tai hallitussa säilössä oleva avain ei koskaan tule tiedostoksi, ja sen rekisteröintipolku on yleensä erillinen työkalu eikä OpenSSL-komento. Kummassakin tapauksessa kenenkään ei tarvitse nähdä yksityistä puoliskoa.

Ohjelmistokulku näyttää tältä, kun avain ja pyyntö luodaan yhdessä istunnossa:

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"

Rivi umask on tärkeämpi kuin miltä näyttää. Ilman sitä avain kirjoitetaan kaikkien luettavaksi järjestelmässä, jonka oletusoikeudet ovat sallivat, ja tiedoston kopioiminen myöhemmin levittää sitä. Olemassa olevan avaimen uudelleenkäyttö on perusteltua, kun se on jo suojattu ja vastaa käytäntöäsi; uuden luominen joka laitteelle on helpompi perustella.

Vaihe 2: laita identiteetti pyyntöön, älä sähköpostiin

Päätä, mitä VPN todella todentaa, ennen kuin pyyntö luodaan, koska se vastaus kuuluu CSR:n sisään. OpenVPN sitoo asiakkaan identiteetin perinteisesti varmenteen yleisnimeen, ja työkalut kuten strongSwan sovittavat identiteettimerkkijonon subjektiin tai subjektin vaihtoehtoiseen nimeen. Sähköposti, joka sanoo nimeni olevan alice, ei ole todiste, ja pyyntö, jonka subjekti sanoo saman, on vain hiukan parempi.

Lisää subjektin vaihtoehtoinen nimi, kun vahvistimesi tarkistaa sellaisen, koska moderni sovitus jättää usein vanhan CN:n huomiotta:

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

Pidä CN lyhyenä, vakaana ja tilille sidottuna eikä kannettavan mallille. Nimi, joka sisältää käyttäjän laitteen sarjanumeron, on tukiongelma, joka odottaa ensimmäistä laitevaihtoa.

Vaihe 3: vahvista pyyntö ennen kuin allekirjoitat sen

Myöntäjä vahvistaa kaksi eri asiaa, ja niiden sekoittaminen on klassinen virhe. Ensiksi, että pyyntö on sisäisesti johdonmukainen: allekirjoitus vahvistetaan sitä kantavaa julkista avainta vastaan. Toiseksi, että pyytäjällä on oikeus siihen, mitä pyyntö vaatii, eikä siihen pysty mikään kryptografinen tarkistus vastaamaan.

Mekaaninen osa on yksi komento, ja sen pitäisi tulostaa vahvistustulos subjektin kanssa:

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

Huomaa, mitä se todistaa. Vahvistuva pyyntö näyttää vain, että lähettäjällä oli vastaava yksityinen avain lähetyshetkellä; se ei todista, että lähettäjä on subjektissa nimetty henkilö, eikä se valtuuta pyydettyä ryhmä- tai reittikäyttöä. Rekisteröinnin tarkastus on erillinen portti, ja pyyntö ryhmästä, jota kukaan ei hyväksynyt, pitäisi hylätä eikä hiljaa muokata.

Vaihe 4: valtuuta ja allekirjoita sitten eksplisiittisillä laajennuksilla

Allekirjoittaminen on paikka, jossa CA päättää käytännöstä sen sijaan että hyväksyisi pyynnön sellaisenaan. Voimassaolo, avaimen käyttö ja roolilaajennus kuuluvat laajennustiedostoon, eivät oletuksiin, joita et muista puolen vuoden päästä. VPN-todennuksen asiakasvarmenne tarvitsee asiakastodennuksen tarkoituksekseen.

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

Käytä -CAserial olemassa olevan sarjanumerotiedoston kanssa, jos sellainen on jo käytössä, ja pidä CA:n avain verkon ulkopuolella tai missä tahansa suojatussa säilössä, jonka käytäntösi nimeää. Varmennusten sarjanumeroiden täytyy olla ainutlaatuisia myöntäjäkohtaisesti; sarjanumerotiedoston luominen tyhjästä riski törmäyksille, jotka tekevät mitätöinnistä epäselvän.

Kirjaa, mitä myönnettiin: sarjanumero, subjekti, pyydetty identiteetti, hyväksyjä ja vanheneminen. Juuri siitä kirjauksesta mitätöintipäätös myöhemmin riippuu, eikä sitä voi rakentaa uudelleen pelkästä varmenteesta, jos rekisteröinnin jälki elää vain postilaatikossa.

Vaihe 5: asenna se vastaavan avaimen viereen ja todista pari

Asiakas vastaanottaa varmenteen ja myöntäjän ketjun, ei koskaan avainta. Ennen yhdistämistä vahvista, että varmenne todella muodostaa parin levyllä jo olevan avaimen kanssa, koska epäsopiva pari tuottaa hämmentävän kättelyvirheen paljon myöhemmin:

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

Kahden tiivisteen täytyy täsmätä. Yhdistä sitten ja vahvista, että identiteetti, jonka palvelin kirjaa, on se, jonka valtuutit, eikä vain se, että tunneli nousi. Jos avain katoaa tai laite vaihdetaan, vastaus on mitätöinti plus uusi pyyntö uudesta laitteesta; pyyntö ylläpitäjälle lähettää avain takaisin jostain muualta ei palauta alkuperäistä ja rikkoo hiljaa mallin, joka teki pyynnöstä turvallisen.