Ohranite korensko CA VPN brez povezave in vseeno izdajajte potrdila

Vaš VPN odgovarja na povezave ob 3 uri zjutraj, medtem ko stroj, ki podpisuje njegova potrdila, stoji izklopljen v predalu. Odjemalec, ki preverja strežniško potrdilo, nikoli ne kontaktira vaše CA, zato CA ni treba biti dosegljiva za nobeno povezavo. Del, ki zahteva načrtovanje, je dan, ko je treba potrdilo izdati, podaljšati ali preklicati medtem ko korenski ključ ostaja zaklenjen.

Kaj povezava v resnici preverja

Ko se odjemalec OpenVPN poveže, prehodi verigo podpisov od listnega potrdila strežnika navzgor do potrdila CA, ki mu že zaupa, preveri obdobje veljavnosti in, če profil tako pravi, pogleda seznam preklicev. Nikoli ne išče vaše korenske CA. Strežnik naredi zrcalno dejanje za odjemalčeva potrdila. V trenutku povezave so prisotni le list, vmesno potrdilo in paket zaupanja, ki ste ga razdelili prej.

Kar v resnici spodleti, je ena od treh stvari: podpisni ključ ni na voljo ob izdaji, seznam preklicev je zastarel ali je paket zaupanja odjemalca starejši od verige, ki jo predstavi strežnik. Prvo je težava procesa; drugi dve sta težavi distribucije. Nobena ne zahteva, da je korenski ključ na spletu, in upravljana storitev VPN, ki za preverjanje pristnosti tunela zahteva zasebno potrdilo, le premakne podpisno oblast k ponudniku. Azure od točke do mesta deluje obratno: naložite korensko potrdilo in potrdila, podpisana pod njim, veljajo za zaupanja vredna, zato vprašajte, kdo podpisuje, kdo preverja in kako se potrdilo prekliče zgodaj.

Zgradite koren na gostitelju, ki nikoli ne dobi naslova

Koren brez povezave se uporablja redko: za podpis potrdila posredniške CA in pozneje za njegovo podaljšanje ali preklic. Vse ostalo se zgodi raven nižje. Delo s korenom opravite na stroju, ki je ločen od omrežja, po možnosti iz živega sistema, in zabeležite, kdo je bil v sobi. Ukazi predpostavljajo OpenSSL 1.1.1 ali novejši, ker -addext v starejših gradnjah ni.

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"

Ustvarite posredniško potrdilo na podpisnem gostitelju in na napravo brez povezave odnesite le njegovo zahtevo. Koren to zahtevo podpiše z ničelno dolžino poti, zato posredniška CA lahko podpisuje končna potrdila, ne more pa ustvariti druge CA pod seboj. Ta ena razširitev prepreči ogroženemu podpisnemu gostitelju, da bi ustvaril oblast, enakovredno korenu. Uporabite ECDSA le, če vsak odjemalec izvaja OpenVPN 2.4 ali novejši; sicer ustvarite ključe RSA in ohranite enak potek.

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 vsebuje basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign in authorityKeyIdentifier=keyid:always. Vrnite korenski ključ v njegov sef, preden podpisnega gostitelja znova povežete. Če mora koren znati preklicati posredniško potrdilo, ga podpišite s openssl ca -config root.cnf -extensions intermediate_ca proti index.txt na korenski ravni namesto openssl x509 -req, da se serijska številka zabeleži; nato pošljite dobljeni korenski seznam v odjemalčev profil, kjer ga datotečni crl-verify prebere ob zagonu. Odjemalcem pošljite paket z obema potrdiloma CA; sam list se proti korenu ne bo preveril.

Izdajajte liste iz posredniške CA, z bazo podatkov

Podpisovanje s openssl x509 -req deluje, dokler ne potrebujete preklica, ker nič ne zabeleži serijske številke. Uporabite openssl ca od prvega potrdila, da serijska številka, veljavnost in stanje preklica živijo v eni bazi podatkov. Ustvarite datoteke baze podatkov enkrat in nato usmerite konfiguracijo nanje:

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

Vrstica uporabe ključa predpostavlja ključ ECDSA; za RSA dodajte keyEncipherment. Vsakemu odjemalcu dajte njegovo skupno ime, ker OpenVPN prepozna povezavo po tem polju, in dveh prenosnikov, ki si delita CN=vpn-client, ni mogoče razlikovati v dnevnikih, v pravilih client-config-dir ali v katerem koli potisku na uporabnika, in izgubite pripis, ki naredi odločitev o preklicu branljivo. Izdajte in preverite list tako:

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

Podpisni ključ hranite za mejo politike, namesto da bi ga kopirali na gostitelja VPN: majhna storitev, ki preveri zahtevo, preveri skupno ime proti seznamu dovoljenih in vrne le potrdilo. Beležite vsako serijsko številko; dnevnik je edina povezava med potrdilom in osebo, ki ga je zahtevala.

Objavite preklic, ne da bi zbudili koren

Odjemalčeva potrdila prekliče posredniška CA, nikoli koren. Korenski seznam je pomemben le, ko je posredniška CA požgana. Usmerite strežnik na posredniški seznam s crl-verify. Datotečni CRL se naloži ob zagonu storitve, zato ga po vsakem ponovnem ustvarjanju znova naložite; imenikova oblika bere stanje v trenutku povezave in stane eno datoteko na serijsko številko.

Prekličite in znova ustvarite z dvema ukazoma iz iste baze podatkov:

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

Nato opazujte uro. CRL nosi polje naslednje posodobitve, in ko ta datum mine, preverjajoča stran seznam zavrne, namesto da bi ga prezrla. Mesečno ponovno ustvarjanje s default_crl_days = 30 pušča rezervo; letno ne. Krajše življenjske dobe listov so zanesljivejši nadzor, ker preklic velja le tam, kjer se seznam preverja.

Preizkusite verigo in nato zapišite obred

Ponovite štiri okvare, preden zaupate zasnovi. Preverite verigo s openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Povežite se s poteklim odjemalčevim potrdilom in potrdite, da ga strežnik zavrne. Prekličite testnega odjemalca, znova naložite in potrdite, da seznam učinkuje. Premaknite uro gostitelja za en dan naprej, ker lahko napačna ura izda in zavrne potrdila, ki so videti veljavna drugje.

Koren brez povezave je nadzor le, če obstaja papir: dve imenovani osebi za obred, evidenca vsake podpisane serijske številke, šifrirana varnostna kopija, shranjena ločeno od stroja, in preskus obnovitve na izoliranem gostitelju. Med istim obredom podpišite nadomestno posredniško CA, da vas mrtvi podpisni gostitelj ne prisili, da koren odklenete ob polnoči.

Preden to razglasite za dokončano, potrdite pet stvari: korenski ključ ni na omrežnem gostitelju, posredniški ključ živi le na podpisnem gostitelju, odjemalčev paket nosi obe potrdili CA, CRL ima prihodnjo naslednjo posodobitev in nekdo ima vnos v koledarju za vsak iztek v verigi. Če ena manjka, je nastavitev, ki je videti brez povezave, le nedokumentirana.