Kako generirati ključ VPN klijenta i poslati CSR na potpisivanje

Prije ili kasnije korisnik VPN-a ponudi da pošalje privatni ključ e-poštom kako bi administrator mogao izraditi certifikat, i upravo tu ponudu treba odbiti. Radni tok drži ključ na klijentu od prve naredbe: klijent ga generira, šalje zahtjev za potpisivanje certifikata, izdavatelj ga provjerava i odobrava, a potpisani certifikat se vraća i staje uz ključ koji ga je stvorio. Kontrolni popis u nastavku pada zatvoreno na svakom koraku, i to je poanta, jer su dva od pet koraka upravo oni koje ljudi preskaču kad su u žurbi.

Korak 1: generirajte ključ tamo gdje će živjeti

Generirajte na stroju koji će držati ključ i ostavite ga tamo. Softverski ključ završava u datoteci sa strogim dopuštenjima; ključ podržan hardverom ili u upravljanom spremištu nikada ne postaje datoteka, a njegov put upisa obično je zaseban alat, a ne naredba OpenSSL. U svakom slučaju, nitko ne treba vidjeti privatnu polovicu.

Softverski tok izgleda ovako, s ključem i zahtjevom stvorenim u jednoj sesiji:

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"

Redak umask važniji je nego što izgleda. Bez njega ključ se zapisuje čitljiv svima na sustavu s dopuštenjima po zadanome, a kasnije kopiranje datoteke to širi. Ponovno korištenje postojećeg ključa legitimno je kad je već zaštićen i odgovara vašoj politici; generiranje novoga za svaki uređaj lakše je objasniti.

Korak 2: stavite identitet u zahtjev, ne u e-poštu

Odlučite što VPN zapravo autentificira prije nego što se zahtjev stvori, jer taj odgovor pripada unutar CSR-a. OpenVPN tradicionalno veže identitet klijenta uz zajedničko ime certifikata, a alati poput strongSwan uspoređuju niz identiteta sa subjektom ili alternativnim imenom subjekta. E-pošta koja kaže da se zovem alice nije dokaz, a zahtjev čiji subjekt kaže isto tek je neznatno bolji.

Dodajte alternativno ime subjekta kad ga vaš provjeravatelj provjerava, jer moderno uparivanje često zanemaruje naslijeđeni CN:

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

Držite CN kratkim, stabilnim i vezanim uz račun, a ne uz model prijenosnika. Ime koje sadrži serijski broj korisnikovog uređaja jest problem podrške koji čeka prvu zamjenu hardvera.

Korak 3: provjerite zahtjev prije nego što ga potpišete

Izdavatelj provjerava dvije različite stvari, a njihovo poistovjećivanje klasična je pogreška. Prvo, da je zahtjev interno dosljedan: potpis se provjerava prema javnom ključu koji nosi. Drugo, da polagatelj ima pravo na ono što zahtjev traži, a na to ne može odgovoriti nijedna kriptografska provjera.

Mehanički dio je jedna naredba i trebala bi ispisati rezultat provjere zajedno sa subjektom:

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

Obratite pozornost na to što to dokazuje. Zahtjev koji prolazi provjeru pokazuje samo da je pošiljatelj imao odgovarajući privatni ključ u trenutku predaje; ne dokazuje da je pošiljatelj osoba navedena u subjektu i ne odobrava pristup grupi ili ruti koja se traži. Pregled upisa zasebna su vrata, a zahtjev koji traži grupu koju nitko nije odobrio treba odbiti, a ne tiho urediti.

Korak 4: odobrite, zatim potpišite s eksplicitnim ekstenzijama

Potpisivanje je mjesto gdje CA odlučuje o politici umjesto da prihvati zahtjev doslovno. Valjanost, korištenje ključa i ekstenzija uloge pripadaju u datoteku ekstenzija, a ne u zadane vrijednosti koje nećete moći prisjetiti šest mjeseci kasnije. Klijentski certifikat za autentifikaciju VPN-a treba klijentsku autentifikaciju kao svoju namjenu.

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

Koristite -CAserial s postojećom datotekom serijskih brojeva ako se jedna već upotrebljava, i držite CA ključ izvan mreže ili u kojem god zaštićenom spremištu navodi vaša politika. Serijski brojevi certifikata moraju biti jedinstveni po izdavatelju; ponovno stvaranje datoteke serijskih brojeva od nule riskira kolizije koje opoziv čine dvosmislenim.

Zabilježite što je izdano: serijski broj, subjekt, traženi identitet, osobu koja je odobrila i rok. Taj zapis je ono o čemu kasnije ovisi odluka o opozivu i ne može se obnoviti samo iz certifikata ako trag upisa živi isključivo u poštanskom sandučiću.

Korak 5: instalirajte ga uz odgovarajući ključ i dokažite uparivanje

Klijent prima certifikat i lanac izdavatelja, nikada ključ. Prije povezivanja potvrdite da se certifikat doista uparuje s ključem koji je već na disku, jer neusklađeni par proizvodi zbunjujući neuspjeh rukovanja mnogo kasnije:

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

Dva sažetka moraju se podudarati. Zatim se povežite i potvrdite da je identitet koji poslužitelj bilježi onaj koji ste odobrili, a ne samo da se tunel podigao. Ako se ključ izgubi ili se uređaj zamijeni, odgovor je opoziv plus novi zahtjev s novog uređaja; traženje da administrator pošalje ključ s nekog drugog mjesta ne vraća izvornik i tiho ruši model koji je zahtjev činio sigurnim.