Jak vygenerovat klientský klíč VPN a odeslat CSR k podpisu

Dříve či později nabídne uživatel VPN, že pošle soukromý klíč e-mailem, aby správce mohl vytvořit certifikát, a právě tuto nabídku je třeba odmítnout. Fungující postup drží klíč u klienta od prvního příkazu: klient ho vygeneruje, odešle žádost o podepsání certifikátu, vydavatel ji ověří a schválí a podepsaný certifikát se vrátí a leží vedle klíče, který ho vytvořil. Kontrolní seznam níže selhává zavřeně v každém kroku, a o to jde, protože dva z pěti kroků jsou právě ty, které lidé ve spěchu vynechávají.

Krok 1: vygenerujte klíč tam, kde bude žít

Generujte na stroji, který bude klíč držet, a nechte ho tam. Softwarový klíč skončí v souboru s omezujícími právy; klíč podporovaný hardwarem nebo v řízeném úložišti se nikdy nestane souborem a jeho cesta zápisu je obvykle samostatný nástroj, nikoli příkaz OpenSSL. Ať tak či onak, nikdo nemusí vidět soukromou polovinu.

Softwarový postup vypadá takto, klíč i žádost vznikají v jedné relaci:

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"

Řádek umask je důležitější, než vypadá. Bez něj se klíč zapíše čitelný pro všechny na systému s výchozími právy a pozdější kopírování souboru to rozšíří. Opětovné použití existujícího klíče je legitimní, když je už chráněný a odpovídá vaší politice; generovat nový pro každé zařízení je snáze obhajitelné.

Krok 2: vložte identitu do žádosti, ne do e-mailu

Rozhodněte, co VPN skutečně autentizuje, dříve než žádost vznikne, protože tato odpověď patří dovnitř CSR. OpenVPN tradičně váže identitu klienta na společné jméno certifikátu a nástroje jako strongSwan porovnávají řetězec identity se subjektem nebo alternativním jménem subjektu. E-mail, který říká, že se jmenuji alice, není důkaz a žádost, jejíž subjekt říká totéž, je jen o málo lepší.

Přidejte alternativní jméno subjektu, když ho váš ověřovatel kontroluje, protože moderní párování č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átké, stabilní a vázané na účet, nikoli na model notebooku. Jméno obsahující sériové číslo uživatelova zařízení je problém podpory, který čeká na první výměnu hardwaru.

Krok 3: ověřte žádost, než ji podepíšete

Vydavatel ověřuje dvě různé věci a jejich slučování je klasická chyba. Za prvé, že žádost je vnitřně konzistentní: podpis se ověřuje proti veřejnému klíči, který nese. Za druhé, že žadatel má nárok na to, co žádost žádá, a na to žádná kryptografická kontrola neumí odpovědět.

Mechanická část je jeden příkaz a měl by vypsat výsledek ověření spolu se subjektem:

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

Všimněte si, co to dokazuje. Žádost, která projde ověřením, ukazuje jen to, že odesílatel měl v době podání odpovídající soukromý klíč; nedokazuje, že odesílatel je osoba uvedená v subjektu, a neautorizuje přístup ke skupině nebo trase, která se žádá. Přezkum zápisu je samostatná brána a žádost o skupinu, kterou nikdo neschválil, má být odmítnuta, ne tiše upravena.

Krok 4: autorizujte a poté podepište s explicitními rozšířeními

Podepisování je místo, kde CA rozhoduje o politice, místo aby žádost přijala doslova. Platnost, použití klíče a rozšíření role patří do souboru rozšíření, ne do výchozích hodnot, které si po šesti měsících nevybavíte. Klientský certifikát pro autentizaci VPN potřebuje jako účel autentizaci 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žijte -CAserial s existujícím souborem sériových čísel, pokud se nějaký už používá, a držte klíč CA offline nebo v jakémkoli chráněném úložišti, které určí vaše politika. Sériová čísla certifikátů musí být jedinečná pro každého vydavatele; znovuvytvoření souboru sériových čísel od nuly riskuje kolize, které činí odvolání nejednoznačným.

Zaznamenejte, co bylo vydáno: sériové číslo, subjekt, požadovanou identitu, schvalující osobu a platnost. Právě na tento záznam se později opírá rozhodnutí o odvolání a nelze ho obnovit jen z certifikátu, pokud stopa zápisu žije pouze v poštovní schránce.

Krok 5: nainstalujte ho vedle odpovídajícího klíče a dokažte pár

Klient obdrží certifikát a řetězec vydavatele, nikdy klíč. Před připojením potvrďte, že certifikát skutečně tvoří pár s klíčem, který už je na disku, protože neshodný pár vyvolá matoucí selhání handshake mnohem později:

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 otisky se musí shodovat. Poté se připojte a potvrďte, že identita, kterou server zaznamená, je ta, kterou jste autorizovali, a ne jen to, že tunel naskočil. Pokud se klíč ztratí nebo se zařízení vymění, odpovědí je odvolání plus nová žádost z nového zařízení; požadavek, aby správce poslal klíč odjinud, originál neobnoví a tiše rozbije model, který žádost činil bezpečnou.