Nechajte koreňovú CA VPN offline a napriek tomu vydávajte certifikáty

Vaša VPN odpovedá na pripojenia o 3 hodine ráno, kým stroj, ktorý podpisuje jej certifikáty, leží vypnutý v zásuvke. Klient overujúci certifikát servera sa nikdy nespojí s vašou CA, takže CA nemusí byť dostupná pre žiadne pripojenie. Časť, ktorá si vyžaduje plánovanie, je deň, kedy treba certifikát vydať, obnoviť alebo odvolať zatiaľ čo koreňový kľúč zostáva uzamknutý.

Čo pripojenie skutočne overuje

Keď sa klient OpenVPN pripojí, prejde reťazec podpisov od listového certifikátu servera nahor k certifikátu CA, ktorému už dôveruje, skontroluje obdobie platnosti a, ak to profil uvádza, pozrie do zoznamu odvolaní. Nikdy nehľadá vašu koreňovú CA. Server robí zrkadlový postup pre klientske certifikáty. V okamihu pripojenia sú prítomné len list, sprostredkujúci certifikát a balík dôvery, ktorý ste distribuovali predtým.

Čo v skutočnosti zlyhá, je jedna z troch vecí: podpisový kľúč nie je pri vydaní dostupný, zoznam odvolaní zostarol alebo je balík dôvery klienta starší ako reťazec, ktorý predkladá server. Prvé je problém procesu; ostatné dve sú problémy distribúcie. Žiadne z nich nevyžaduje, aby bol koreňový kľúč online, a spravovaná služba VPN, ktorá pre autentifikáciu tunela vyžaduje súkromný certifikát, iba presúva podpisovú autoritu na poskytovateľa. Azure bod-do lokality funguje opačne: nahráte koreňový certifikát a certifikáty pod ním podpísané sa považujú za dôveryhodné, preto sa pýtajte, kto podpisuje, kto overuje a ako sa certifikát odvoláva predčasne.

Postavte koreň na hostiteľovi, ktorý nikdy nedostane adresu

Offline koreň sa používa zriedka: na podpis certifikátu sprostredkujúcej CA a neskôr na jeho obnovenie alebo odvolanie. Všetko ostatné sa deje o úroveň nižšie. Prácu s koreňom robte na stroji držanom mimo siete, ak je to možné zo živého systému, a zapíšte, kto bol v miestnosti. Príkazy predpokladajú OpenSSL 1.1.1 alebo novší, pretože -addext v starších zostaveniach nie je.

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"

Vytvorte sprostredkujúci certifikát na podpisovom hostiteľovi a preneste na offline stroj iba jeho žiadosť. Koreň podpíše túto žiadosť s nulovou dĺžkou cesty, takže sprostredkujúca CA môže podpisovať koncové certifikáty, ale nesmie pod sebou vytvoriť ďalšiu CA. To jedno rozšírenie zabráni kompromitovanému podpisovému hostiteľovi vytvoriť autoritu rovnocennú koreňu. ECDSA používajte len vtedy, ak každý klient beží na OpenVPN 2.4 alebo novšom; inak vygenerujte kľúče RSA a ponechajte postup rovnaký.

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. Vráťte koreňový kľúč do trezoru, kým sa podpisový hostiteľ znova pripojí. Ak má koreň vedieť odvolať sprostredkujúci certifikát, podpíšte ho pomocou openssl ca -config root.cnf -extensions intermediate_ca voči index.txt na koreňovej úrovni namiesto openssl x509 -req, aby sa sériové číslo zaznamenalo; potom odošlite výsledný koreňový zoznam v klientskom profile, kde ho súborový crl-verify prečíta pri štarte. Posielajte klientom balík s oboma certifikátmi CA; samotný list sa voči koreňu neoverí.

Vydávajte listy zo sprostredkujúcej CA, s databázou

Podpisovanie pomocou openssl x509 -req funguje dovtedy, kým nepotrebujete odvolať, pretože nič nezaznamenáva sériové číslo. Použite openssl ca od prvého certifikátu, aby sériové číslo, platnosť a stav odvolania žili v jednej databáze. Vytvorte databázové súbory raz a potom na ne nasmerujte konfiguráciu:

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

Riadok použitia kľúča predpokladá kľúč ECDSA; pre RSA pridajte keyEncipherment. Dajte každému klientovi vlastné všeobecné meno, pretože OpenVPN identifikuje pripojenie podľa tohto poľa a dva notebooky zdieľajúce CN=vpn-client sa nedajú rozlíšiť v logoch, v pravidlách client-config-dir ani v žiadnom pushi pre používateľa, a strácate priradenie, ktoré robí rozhodnutie o odvolaní obhájiteľným. Vydajte a overte list 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ý kľúč za hranicou politiky namiesto kopírovania na hostiteľa VPN: malá služba, ktorá overí žiadosť, skontroluje všeobecné meno voči zoznamu povolených a vráti iba certifikát. Zaznamenávajte každé sériové číslo; log je jediné spojenie medzi certifikátom a človekom, ktorý oň požiadal.

Zverejnite odvolanie bez prebudenia koreňa

Klientske certifikáty odvoláva sprostredkujúca CA, nikdy koreň. Koreňový zoznam má význam len vtedy, keď je sprostredkujúca CA spálená. Nasmerujte server na sprostredkujúci zoznam pomocou crl-verify. Súborový CRL sa načíta pri štarte služby, preto ho po každom opätovnom vytvorení znova načítajte; adresárová forma číta stav v okamihu pripojenia a stojí jeden súbor na sériové číslo.

Odvolajte a znova vytvorte dvoma príkazmi z tej istej databázy:

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

Potom sledujte hodiny. CRL nesie pole ďalšej aktualizácie a keď ten dátum prejde, overujúca strana zoznam odmietne namiesto toho, aby ho ignorovala. Mesačné opätovné vytváranie s default_crl_days = 30 necháva rezervu; ročné nie. Kratšie životnosti listov sú spoľahlivejšia kontrola, pretože odvolanie platí len tam, kde sa zoznam kontroluje.

Otestujte reťaz a potom zapíšte ceremóniu

Reprodukujte štyri zlyhania, kým návrhu uveríte. Overte reťaz pomocou openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Pripojte sa s prepadnutým klientskym certifikátom a potvrďte, že ho server odmietne. Odvolajte testovacieho klienta, znova načítajte a potvrďte, že zoznam nadobudne účinnosť. Posuňte hodiny hostiteľa o deň dopredu, pretože nesprávne hodiny môžu vydať a odmietnuť certifikáty, ktoré inde vyzerajú platne.

Offline koreň je kontrola len vtedy, ak existujú papiere: dve menované osoby pre ceremóniu, záznam o každom podpísanom sériovom čísle, šifrovaná záloha uložená oddelene od stroja a test obnovy na izolovanom hostiteľovi. Počas tej istej ceremónie podpíšte záložnú sprostredkujúcu CA, aby vás mŕtvy podpisový hostiteľ nedonútil odomknúť koreň o polnoci.

Predtým, než to označíte za hotové, potvrďte päť vecí: koreňový kľúč nie je na sieťovom hostiteľovi, sprostredkujúci kľúč žije len na podpisovom hostiteľovi, klientsky balík nesie oba certifikáty CA, CRL má budúcu ďalšiu aktualizáciu a niekto vlastní položku v kalendári pre každú expiráciu v reťazi. Ak jedna chýba, nastavenie, ktoré vyzerá offline, je len nedokumentované.