Držite korijenski CA VPN van mreže i ipak izdajte sertifikate
Držite korijenski ključ van mreže, potpisujte krajnje sertifikate posredničkim CA, objavljujte CRL na vrijeme i testirajte lanac prije nego se poveže prvi klijent.
Vaš VPN odgovara na veze u 3 sata ujutro dok mašina koja potpisuje njegove sertifikate stoji isključena u fioci. Klijent koji provjerava sertifikat servera nikada ne kontaktira vaš CA, pa CA ne mora biti dostupan ni za jednu vezu. Dio koji treba planirati jeste dan kada sertifikat mora biti izdat, obnovljen ili opozvan dok korijenski ključ ostaje zaključan.
Šta veza zapravo provjerava
Kada se OpenVPN klijent poveže, on prolazi kroz lanac potpisa od krajnjeg sertifikata servera do CA sertifikata kojem već vjeruje, provjerava period važenja i, ako profil to nalaže, konsultuje listu opozvanih sertifikata. Nikada ne traži vaš korijenski CA. Server radi suprotno za klijentske sertifikate. U trenutku povezivanja prisutni su samo krajnji sertifikat, posrednički i paket povjerenja koji ste ranije distribuirali.
Ono što zapravo zakaže jeste jedna od tri stvari: ključ za potpisivanje nije dostupan pri izdavanju, lista opozvanih sertifikata je zastarjela ili je paket povjerenja klijenta stariji od lanca koji server predstavlja. Prvo je problem procesa; druga dva su problemi distribucije. Nijedno od njih ne zahtijeva da korijenski ključ bude na mreži, a upravljana VPN usluga koja zahtijeva privatni sertifikat za autentifikaciju tunela samo premješta ovlaštenje za potpisivanje na provajdera. Azure point-to-site radi obrnuto: otpremite korijenski sertifikat i sertifikati potpisani ispod njega smatraju se pouzdanim, pa pitajte ko potpisuje, ko provjerava i kako se sertifikat povlači prije roka.
Izgradite korijen na hostu koji nikada ne dobije adresu
Izvanmrežni korijen se koristi rijetko: za potpisivanje sertifikata posredničkog CA i kasnije za njegovo obnavljanje ili opoziv. Sve ostalo se dešava nivo niže. Obavite rad s korijenom na mašini koja se drži van mreže, ako je moguće sa živog sistema, i zabilježite ko je bio u prostoriji. Komande pretpostavljaju OpenSSL 1.1.1 ili noviji, jer -addext nije dostupan u starijim verzijama.
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"
Kreirajte posrednički sertifikat na hostu za potpisivanje i prenesite samo njegov zahtjev na izvanmrežnu mašinu. Korijen potpisuje taj zahtjev s dužinom putanje nula, pa posrednički CA može potpisivati krajnje sertifikate, ali ne može stvoriti drugi CA ispod sebe. To jedno proširenje sprječava kompromitovani host za potpisivanje da stvori ovlaštenje ekvivalentno korijenu. Koristite ECDSA samo ako svaki klijent radi na OpenVPN 2.4 ili novijem; inače generišite RSA ključeve i zadržite isti tok.
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 sadrži basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign i authorityKeyIdentifier=keyid:always. Vratite korijenski ključ u njegov sef prije nego se host za potpisivanje ponovo poveže. Ako korijen mora moći opozvati posrednički sertifikat, potpišite ga pomoću openssl ca -config root.cnf -extensions intermediate_ca prema index.txt na razini korijena umjesto openssl x509 -req, kako bi serijski broj bio zabilježen; zatim pošaljite dobijenu korijensku listu unutar klijentskog profila, gdje je datotečni crl-verify čita pri pokretanju. Pošaljite klijentima paket s oba CA sertifikata; sam krajnji sertifikat neće se provjeriti prema korijenu.
Izdajte krajnje sertifikate iz posredničkog CA, uz bazu podataka
Potpisivanje pomoću openssl x509 -req funkcioniše dok ne zatrebate opoziv, jer ništa ne bilježi serijski broj. Koristite openssl ca od prvog sertifikata kako bi serijski broj, rok i stanje opoziva živjeli u jednoj bazi podataka. Kreirajte datoteke baze podataka jednom, zatim usmjerite konfiguraciju na njih:
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
Linija upotrebe ključa pretpostavlja ECDSA ključ; dodajte keyEncipherment za RSA. Dajte svakom klijentu vlastito uobičajeno ime, jer OpenVPN identifikuje vezu po tom polju, a dva laptopa koja dijele CN=vpn-client ne mogu se razlikovati u zapisima, u pravilima client-config-dir ni u bilo kojem slanju za korisnika, i gubite pripisivanje koje odluku o opozivu čini odbranjivom. Izdajte i provjerite krajnji sertifikat ovako:
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žite ključ za potpisivanje iza granice politike umjesto da ga kopirate na VPN host: mala usluga koja autentificira zahtjev, provjerava uobičajeno ime prema listi dozvoljenih i vraća samo sertifikat. Bilježite svaki serijski broj; zapis je jedina veza između sertifikata i osobe koja ga je tražila.
Objavite opoziv bez buđenja korijena
Klijentske sertifikate opoziva posrednički CA, nikada korijen. Korijenska lista je važna samo kada je posrednički CA spaljen. Usmjerite server na posredničku listu pomoću crl-verify. Datotečni CRL se učitava pri pokretanju usluge, pa ga ponovo učitajte nakon svake regeneracije; direktorijska forma čita stanje u trenutku povezivanja i košta jednu datoteku po serijskom broju.
Opozvite i regenerišite s dvije komande iz iste baze podataka:
openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem
Zatim pratite sat. CRL nosi polje sljedećeg ažuriranja, a kada taj datum prođe, strana koja provjerava odbija listu umjesto da je zanemari. Mjesečna regeneracija s default_crl_days = 30 ostavlja rezervu; godišnja ne. Kraći životni vijek krajnjih sertifikata pouzdanija je kontrola, jer se opoziv primjenjuje samo tamo gdje se lista konsultuje.
Testirajte lanac, zatim zapišite ceremoniju
Reprodukujte četiri kvara prije nego povjerujete dizajnu. Provjerite lanac pomoću openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Povežite se s isteklim klijentskim sertifikatom i potvrdite da ga server odbija. Opozvite testni klijent, ponovo učitajte i potvrdite da lista stupa na snagu. Pomjerite sat hosta dan naprijed, jer pogrešan sat može izdati i odbiti sertifikate koji izgledaju važeći drugdje.
Izvanmrežni korijen je kontrola samo ako postoji papirologija: dvije imenovane osobe za ceremoniju, evidencija svakog potpisanog serijskog broja, šifrovana sigurnosna kopija pohranjena odvojeno od mašine i test obnove na izolovanom hostu. Potpišite rezervni posrednički sertifikat tokom iste ceremonije kako vas mrtav host za potpisivanje ne bi natjerao da otključate korijen u ponoć.
Prije nego što to nazovete završenim, potvrdite pet stvari: korijenski ključ nije na umreženom hostu, posrednički ključ živi samo na hostu za potpisivanje, klijentski paket nosi oba CA sertifikata, CRL ima buduće sljedeće ažuriranje i neko posjeduje kalendarski unos za svaki rok u lancu. Ako jedno nedostaje, postavka koja izgleda izvan mreže samo je nedokumentovana.