Nechte kořenovou CA VPN offline a přesto vydávejte certifikáty

Vaše VPN odpovídá na připojení ve 3 hodiny ráno, zatímco stroj, který podepisuje její certifikáty, leží vypnutý v šuplíku. Klient ověřující certifikát serveru se nikdy nespojí s vaší CA, takže CA nemusí být pro žádné připojení dostupná. Část, která vyžaduje plánování, je den, kdy je třeba certifikát vydat, obnovit nebo odvolat zatímco kořenový klíč zůstává uzamčen.

Co připojení skutečně ověřuje

Když se klient OpenVPN připojí, projde řetězec podpisů od koncového certifikátu serveru až k certifikátu CA, kterému už důvěřuje, zkontroluje období platnosti a, pokud to profil říká, nahlédne do seznamu odvolaných certifikátů. Nikdy nevyhledává vaši kořenovou CA. Server dělá zrcadlový postup pro klientské certifikáty. V okamžiku připojení jsou přítomny jen koncový certifikát, zprostředkující certifikát a balík důvěry, který jste dříve distribuovali.

Co skutečně selže, je jedna ze tří věcí: podpisový klíč není při vydání k dispozici, seznam odvolaných certifikátů zastaral nebo je klientský balík důvěry starší než řetězec, který server předkládá. První je problém procesu; zbylé dvě jsou problémy distribuce. Žádná z nich nevyžaduje, aby byl kořenový klíč online, a spravovaná služba VPN, která pro autentizaci tunelu vyžaduje soukromý certifikát, pouze přesouvá podpisovou pravomoc na poskytovatele. Azure point-to-site funguje opačně: nahrajete kořenový certifikát a certifikáty pod ním podepsané jsou považovány za důvěryhodné, takže se ptejte, kdo podepisuje, kdo ověřuje a jak se certifikát odvolává předčasně.

Postavte kořen na hostiteli, který nikdy nedostane adresu

Offline kořen se používá zřídka: k podpisu certifikátu zprostředkující CA a později k jeho obnovení nebo odvolání. Vše ostatní se odehrává o úroveň níž. Práci s kořenem dělejte na stroji drženém mimo síť, pokud možno z živého systému, a zaznamenejte, kdo byl v místnosti. Příkazy předpokládají OpenSSL 1.1.1 nebo novější, protože -addext ve starších sestaveních není.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Vytvořte zprostředkující certifikát na podpisovém hostiteli a přeneste na offline stroj jen jeho žádost. Kořen tuto žádost podepíše s délkou cesty nula, takže zprostředkující CA může podepisovat koncové certifikáty, ale nesmí pod sebou vytvořit další CA. To jedno rozšíření zabrání kompromitovanému podpisovému hostiteli vytvořit pravomoc rovnocennou kořeni. ECDSA použijte jen tehdy, když každý klient běží na OpenVPN 2.4 nebo novějším; jinak vygenerujte klíče RSA a ponechte postup stejný.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext obsahuje basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign a authorityKeyIdentifier=keyid:always. Vraťte kořenový klíč do trezoru, než se podpisový hostitel znovu připojí. Pokud má kořen umět odvolat zprostředkující certifikát, podepište ho pomocí openssl ca -config root.cnf -extensions intermediate_ca proti index.txt na kořenové úrovni místo openssl x509 -req, aby se sériové číslo zaznamenalo; poté odešlete výsledný kořenový seznam uvnitř klientského profilu, kde ho souborový crl-verify přečte při startu. Posílejte klientům balík s oběma certifikáty CA; samotný koncový certifikát se proti kořeni neověří.

Vydávejte koncové certifikáty ze zprostředkující CA, s databází

Podepisování pomocí openssl x509 -req funguje, dokud nepotřebujete odvolat, protože nic nezaznamenává sériové číslo. Použijte openssl ca od prvního certifikátu, aby sériové číslo, platnost a stav odvolání žily v jedné databázi. Vytvořte databázové soubory jednou a pak na ně namiřte konfiguraci:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

Řádek použití klíče předpokládá klíč ECDSA; pro RSA přidejte keyEncipherment. Dejte každému klientovi vlastní obecné jméno, protože OpenVPN identifikuje připojení podle tohoto pole a dva notebooky sdílející CN=vpn-client nelze v protokolech, v pravidlech client-config-dir ani v žádném pushi pro uživatele rozlišit, a ztrácíte přiřazení, které činí rozhodnutí o odvolání obhajitelným. Vydávejte a ověřujte koncový certifikát takto:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

Držte podpisový klíč za hranicí politiky, místo abyste ho kopírovali na hostitele VPN: malá služba, která ověří žádost, zkontroluje obecné jméno proti seznamu povolených a vrátí jen certifikát. Zaznamenávejte každé sériové číslo; protokol je jediné spojení mezi certifikátem a člověkem, který o něj požádal.

Zveřejněte odvolání, aniž byste probudili kořen

Klientské certifikáty odvolává zprostředkující CA, nikdy kořen. Kořenový seznam má význam jen tehdy, když je zprostředkující CA spálena. Namiřte server na zprostředkující seznam pomocí crl-verify. Souborová CRL se načítá při startu služby, takže po každém znovuvytvoření ji znovu načtěte; adresářová forma čte stav v okamžiku připojení a stojí jeden soubor na sériové číslo.

Odvolejte a znovu vytvořte dvěma příkazy ze stejné databáze:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Pak sledujte hodiny. CRL nese pole příští aktualizace a jakmile ten datum přejde, ověřující protějšek seznam odmítne, místo aby ho ignoroval. Měsíční obnovení s default_crl_days = 30 nechává rezervu; roční ne. Kratší životnost koncových certifikátů je spolehlivější kontrola, protože odvolání platí jen tam, kde se seznam kontroluje.

Otestujte řetěz a pak sepište ceremonii

Reprodukujte čtyři selhání, než návrhu uvěříte. Ověřte řetěz pomocí openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Připojte se s propadlým klientským certifikátem a potvrďte, že ho server odmítne. Odvolejte testovacího klienta, znovu načtěte a potvrďte, že seznam nabyl účinnosti. Posuňte hodiny hostitele o den dopředu, protože špatné hodiny mohou vydat a odmítnout certifikáty, které jinde vypadají platně.

Offline kořen je kontrola jen tehdy, když existují papíry: dva jmenovaní lidé pro ceremonii, záznam o každém podepsaném sériovém čísle, šifrovaná záloha uložená odděleně od stroje a test obnovy na izolovaném hostiteli. Podepište během stejné ceremonie náhradní zprostředkující certifikát, aby vás mrtvý podpisový hostitel nedonutil odemykat kořen o půlnoci.

Než to označíte za hotové, potvrďte pět věcí: kořenový klíč není na síťovém hostiteli, zprostředkující klíč žije jen na podpisovém hostiteli, klientský balík nese oba certifikáty CA, CRL má budoucí příští aktualizaci a někdo vlastní položku v kalendáři pro každou expiraci v řetězu. Pokud jedna chybí, nastavení, které vypadá offline, je jen nezdokumentované.