Ako vygenerovať klientsky kľúč VPN a odoslať CSR na podpis

Skôr či neskôr používateľ VPN ponúkne poslať súkromný kľúč e-mailom, aby správca mohol vytvoriť certifikát, a práve túto ponuku treba odmietnuť. Fungujúci postup drží kľúč u klienta od prvého príkazu: klient ho vygeneruje, odošle žiadosť o podpísanie certifikátu, vydavateľ ju overí a schváli a podpísaný certifikát sa vráti a leží vedľa kľúča, ktorý ho vytvoril. Kontrolný zoznam nižšie zlyháva zavretý v každom kroku, a o to ide, pretože dva z piatich krokov sú práve tie, ktoré ľudia v zhone vynechávajú.

Krok 1: vygenerujte kľúč tam, kde bude žiť

Generujte na stroji, ktorý bude kľúč držať, a nechajte ho tam. Softvérový kľúč skončí v súbore s obmedzujúcimi právami; kľúč podporovaný hardvérom alebo v spravovanom úložisku sa nikdy nestane súborom a jeho cesta zápisu je zvyčajne samostatný nástroj, nie príkaz OpenSSL. Tak či onak, nikto nemusí vidieť súkromnú polovicu.

Softvérový postup vyzerá takto, kľúč aj žiadosť vznikajú v jednej relácii:

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"

Riadok umask je dôležitejší, než vyzerá. Bez neho sa kľúč zapíše čitateľný pre všetkých na systéme s predvolenými právami a neskoršie kopírovanie súboru to rozšíri. Opätovné použitie existujúceho kľúča je legitímne, keď je už chránený a zodpovedá vašej politike; generovať nový pre každé zariadenie sa dá ľahšie obhájiť.

Krok 2: vložte identitu do žiadosti, nie do e-mailu

Rozhodnite, čo VPN skutočne autentifikuje, skôr než žiadosť vznikne, pretože tá odpoveď patrí dovnútra CSR. OpenVPN tradične viaže identitu klienta na spoločné meno certifikátu a nástroje ako strongSwan porovnávajú reťazec identity so subjektom alebo alternatívnym menom subjektu. E-mail, ktorý hovorí, že sa volám alice, nie je dôkaz a žiadosť, ktorej subjekt hovorí to isté, je len o niečo lepšia.

Pridajte alternatívne meno subjektu, keď ho váš overovateľ kontroluje, pretože moderné párovanie často ignoruje staré CN:

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

Držte CN krátke, stabilné a viazané na účet, nie na model notebooku. Meno obsahujúce sériové číslo používateľovho zariadenia je problém podpory, ktorý čaká na prvú výmenu hardvéru.

Krok 3: overte žiadosť skôr, než ju podpíšete

Vydavateľ overuje dve rôzne veci a ich zlievanie je klasická chyba. Po prvé, že žiadosť je vnútorne konzistentná: podpis sa overuje voči verejnému kľúču, ktorý nesie. Po druhé, že žiadateľ má právo na to, čo žiadosť žiada, a na to nedokáže odpovedať žiadna kryptografická kontrola.

Mechanická časť je jeden príkaz a mal by vypísať výsledok overenia spolu so subjektom:

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

Všimnite si, čo to dokazuje. Žiadosť, ktorá prejde overením, ukazuje len to, že odosielateľ mal v čase podania zodpovedajúci súkromný kľúč; nedokazuje, že odosielateľ je osoba uvedená v subjekte, a neautorizuje prístup k požadovanej skupine alebo trase. Preskúmanie zápisu je samostatná brána a žiadosť o skupinu, ktorú nikto neschválil, má byť odmietnutá, nie ticho upravená.

Krok 4: autorizujte a potom podpíšte s explicitnými rozšíreniami

Podpisovanie je miesto, kde CA rozhoduje o politike, namiesto toho, aby žiadosť prijala doslovne. Platnosť, použitie kľúča a rozšírenie roly patria do súboru rozšírení, nie do predvolených hodnôt, ktoré si po pol roku nevybavíte. Klientsky certifikát na autentifikáciu VPN potrebuje ako účel autentifikáciu klienta.

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

Použite -CAserial s existujúcim súborom sériových čísel, ak sa už nejaký používa, a držte kľúč CA offline alebo v akomkoľvek chránenom úložisku, ktoré určí vaša politika. Sériové čísla certifikátov musia byť jedinečné pre každého vydavateľa; opätovné vytvorenie súboru sériových čísel od nuly riskuje kolízie, ktoré robia odvolanie nejednoznačným.

Zaznamenajte, čo bolo vydané: sériové číslo, subjekt, požadovanú identitu, schvaľujúcu osobu a platnosť. Práve na tento záznam sa neskôr opiera rozhodnutie o odvolaní a nemožno ho obnoviť len z certifikátu, ak stopa zápisu žije iba v poštovej schránke.

Krok 5: nainštalujte ho vedľa zodpovedajúceho kľúča a dokážte pár

Klient dostane certifikát a reťazec vydavateľa, nikdy kľúč. Pred pripojením potvrďte, že certifikát skutočne tvorí pár s kľúčom, ktorý už je na disku, pretože nezhodný pár vyvolá mätúce zlyhanie podania ruky oveľa neskôr:

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

Oba odtlačky sa musia zhodovať. Potom sa pripojte a potvrďte, že identita, ktorú server zaznamenáva, je tá, ktorú ste autorizovali, a nie len to, že tunel nabehol. Ak sa kľúč stratí alebo zariadenie vymení, odpoveďou je odvolanie plus nová žiadosť z nového zariadenia; požiadavka, aby správca poslal kľúč odinakiaľ, originál neobnoví a ticho rozbije model, ktorý robil žiadosť bezpečnou.