Kaip sugeneruoti VPN kliento raktą ir pateikti CSR pasirašymui

Anksčiau ar vėliau VPN naudotojas pasiūlo atsiųsti privatų raktą elektroniniu paštu, kad administratorius galėtų sukurti sertifikatą, ir būtent šio pasiūlymo reikia atsisakyti. Veikiantis procesas laiko raktą kliente nuo pirmos komandos: klientas jį sugeneruoja, išsiunčia sertifikato pasirašymo užklausą, išdavėjas ją patikrina ir patvirtina, o pasirašytas sertifikatas grįžta atsistoti šalia rakto, kuris jį sukūrė. Toliau pateiktas kontrolinis sąrašas kiekviename žingsnyje nepavyksta uždarai, ir tai yra esmė, nes du iš penkių žingsnių yra būtent tie, kuriuos žmonės praleidžia, kai skuba.

1 žingsnis: sugeneruokite raktą ten, kur jis gyvens

Generuokite mašinoje, kuri laikys raktą, ir palikite jį ten. Programinės įrangos raktas atsiduria byloje su griežtomis teisėmis; aparatinės įrangos palaikomas arba valdomoje saugykloje esantis raktas niekada netampa byla, o jo registracijos kelias paprastai yra atskiras įrankis, o ne OpenSSL komanda. Kad ir kaip būtų, niekam nereikia matyti privačios pusės.

Programinės įrangos eiga atrodo taip, raktas ir užklausa sukuriami vienoje sesijoje:

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"

umask eilutė svarbesnė, nei atrodo. Be jos raktas įrašomas visiems skaitomas sistemoje, kuri pagal nutylėjimą leidžianti, o vėlesnis bylos kopijavimas tai paskleidžia. Esamo rakto naudojimas iš naujo yra teisėtas, kai jis jau apsaugotas ir atitinka jūsų politiką; kurti naują kiekvienam įrenginiui lengviau pagrįsti.

2 žingsnis: įdėkite tapatybę į užklausą, o ne į elektroninį laišką

Nuspręskite, ką VPN iš tikrųjų autentifikuoja, prieš sukuriant užklausą, nes tas atsakymas priklauso CSR viduje. OpenVPN tradiciškai susieja kliento tapatybę su sertifikato bendruoju vardu, o tokie įrankiai kaip strongSwan lygina tapatybės eilutę su subjektu arba alternatyviu subjekto vardu. Elektroninis laiškas, sakantis, kad mano vardas alice, nėra įrodymas, o užklausa, kurios subjektas sako tą patį, yra tik šiek tiek geresnė.

Pridėkite alternatyvų subjekto vardą, kai jūsų tikrintuvas jį tikrina, nes šiuolaikinis atitikimas dažnai nepaiso senojo CN:

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

Laikykite CN trumpą, stabilų ir susietą su paskyra, o ne su nešiojamojo kompiuterio modeliu. Vardas, kuriame yra naudotojo įrenginio serijos numeris, yra palaikymo problema, laukianti pirmo aparatinės įrangos pakeitimo.

3 žingsnis: patikrinkite užklausą prieš pasirašydami

Išdavėjas tikrina du skirtingus dalykus, ir jų sumaišymas yra klasikinė klaida. Pirma, kad užklausa būtų vidiniu požiūriu nuosekli: parašas tikrinamas pagal joje esantį viešąjį raktą. Antra, kad prašytojas turi teisę į tai, ko prašo užklausa, ir į tai negali atsakyti joks kriptografinis patikrinimas.

Mechaninė dalis yra viena komanda, ir ji turėtų išspausdinti patikrinimo rezultatą kartu su subjektu:

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

Atkreipkite dėmesį, ką tai įrodo. Patikrinta užklausa rodo tik tai, kad siuntėjas pateikimo metu turėjo atitinkamą privatų raktą; ji neįrodo, kad siuntėjas yra subjekte nurodytas asmuo, ir neįgalioja prašomos grupės ar maršruto prieigos. Registracijos peržiūra yra atskiri vartai, o užklausa dėl grupės, kurios niekas nepatvirtino, turėtų būti atmesta, o ne tyliai redaguojama.

4 žingsnis: įgaliokite, tada pasirašykite su aiškiais plėtiniais

Pasirašymas yra vieta, kur CA nusprendžia politiką, o ne priima užklausą pažodžiui. Galiojimas, rakto naudojimas ir vaidmens plėtinys priklauso plėtinių bylai, o ne numatytosioms reikšmėms, kurių neprisiminsite po pusės metų. VPN autentifikavimo kliento sertifikatui kaip paskirtis reikalingas kliento autentifikavimas.

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

Naudokite -CAserial su esama serijos numerių byla, jei tokia jau naudojama, ir laikykite CA raktą neprisijungus arba bet kurioje apsaugotoje saugykloje, kurią nurodo jūsų politika. Sertifikatų serijos numeriai turi būti unikalūs kiekvienam išdavėjui; serijos numerių bylos atkūrimas nuo nulio rizikuoja susidūrimais, dėl kurių atšaukimas tampa dviprasmis.

Užrašykite, kas buvo išduota: serijos numerį, subjektą, prašytą tapatybę, patvirtinusį asmenį ir galiojimo pabaigą. Būtent nuo šio įrašo vėliau priklauso atšaukimo sprendimas, ir jo negalima atkurti vien iš sertifikato, jei registracijos pėdsakas gyvena tik pašto dėžutėje.

5 žingsnis: įdiekite jį šalia atitinkamo rakto ir įrodykite porą

Klientas gauna sertifikatą ir išdavėjo grandinę, niekada rakto. Prieš prisijungdami patvirtinkite, kad sertifikatas tikrai sudaro porą su diske jau esančiu raktu, nes nesutampanti pora daug vėliau sukelia klaidinančią rankos paspaudimo klaidą:

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

Abu maišos kodai turi sutapti. Tada prisijunkite ir patvirtinkite, kad tapatybė, kurią serveris registruoja, yra ta, kurią įgaliojote, o ne tik tai, kad tunelis pakilo. Jei raktas pametamas arba įrenginys pakeičiamas, atsakymas yra atšaukimas ir nauja užklausa iš naujo įrenginio; prašymas administratoriui atsiųsti raktą atgal iš kitur neatkuria originalo ir tyliai sugriauna modelį, kuris padarė užklausą saugią.