Țineți CA rădăcină a VPN offline și totuși emiteți certificate

VPN-ul dvs. răspunde conexiunilor la ora 3 dimineața în timp ce mașina care îi semnează certificatele stă oprită într-un sertar. Un client care validează certificatul serverului nu contactează niciodată CA-ul dvs., așa că CA-ul nu trebuie să fie accesibil pentru nicio conexiune. Partea care necesită planificare este ziua în care un certificat trebuie emis, reînnoit sau revocat în timp ce cheia rădăcină rămâne încuiată.

Ce validează de fapt o conexiune

Când clientul OpenVPN se conectează, parcurge lanțul de semnături de la certificatul frunză al serverului până la un certificat CA în care are deja încredere, verifică fereastra de valabilitate și, dacă profilul o spune, consultă o listă de revocare. Nu caută niciodată CA-ul rădăcină. Serverul face imaginea în oglindă pentru certificatele clienților. În momentul conectării sunt prezente doar frunza, intermediarul și pachetul de încredere distribuit anterior.

Ce eșuează de fapt este unul dintre trei lucruri: cheia de semnare nu este disponibilă la emitere, o listă de revocare a devenit învechită sau pachetul de încredere al clientului este mai vechi decât lanțul prezentat de server. Primul este o problemă de proces; celelalte două sunt probleme de distribuție. Niciunul nu cere ca cheia rădăcină să fie online, iar un serviciu VPN gestionat care cere un certificat privat pentru autentificarea tunelului doar mută autoritatea de semnare la furnizor. Azure punct-la-site funcționează invers: încărcați un certificat rădăcină și certificatele semnate sub el sunt considerate de încredere, așa că întrebați cine semnează, cine validează și cum este retras un certificat mai devreme.

Construiți rădăcina pe un host care nu primește niciodată o adresă

O rădăcină offline este folosită rar: pentru a semna certificatul CA intermediar și, mai târziu, pentru a-l reînnoi sau revoca. Tot restul se întâmplă un nivel mai jos. Faceți munca rădăcinii pe o mașină ținută în afara rețelei, dacă este posibil dintr-un sistem live, și notați cine a fost în cameră. Comenzile presupun OpenSSL 1.1.1 sau mai nou, deoarece -addext nu există în compilările vechi.

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"

Creați intermediarul pe hostul de semnare și duceți doar cererea lui la mașina offline. Rădăcina semnează acea cerere cu lungime de cale zero, astfel încât CA-ul intermediar poate semna certificate de punct final, dar nu poate crea alt CA sub el. Acea singură extensie împiedică un host de semnare compromis să creeze o autoritate echivalentă rădăcinii. Folosiți ECDSA doar dacă fiecare client rulează OpenVPN 2.4 sau mai nou; altfel generați chei RSA și păstrați același flux.

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 conține basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign și authorityKeyIdentifier=keyid:always. Puneți cheia rădăcină înapoi în seif înainte de reconectarea hostului de semnare. Dacă rădăcina trebuie să poată revoca intermediarul, semnați-l cu openssl ca -config root.cnf -extensions intermediate_ca împotriva unui index.txt de nivel rădăcină în loc de openssl x509 -req, ca numărul de serie să fie înregistrat; apoi trimiteți lista rădăcină rezultată în profilul clientului, unde un crl-verify bazat pe fișier o citește la pornire. Trimiteți clienților un pachet cu ambele certificate CA; o frunză singură nu se va valida împotriva rădăcinii.

Emiteți frunze din intermediar, cu o bază de date

Semnarea cu openssl x509 -req funcționează până când trebuie să revocați, deoarece nimic nu înregistrează numărul de serie. Folosiți openssl ca de la primul certificat, astfel încât numărul de serie, expirarea și starea de revocare să trăiască într-o singură bază de date. Creați fișierele bazei de date o dată, apoi îndreptați configurația spre ele:

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

Linia de utilizare a cheii presupune o cheie ECDSA; adăugați keyEncipherment pentru RSA. Dați fiecărui client propriul nume comun, deoarece OpenVPN identifică o conexiune după acel câmp, iar două laptopuri care partajează CN=vpn-client nu pot fi distinse în jurnale, în regulile client-config-dir sau în orice push pe utilizator, și pierdeți atribuirea care face o decizie de revocare apărabilă. Emiteți și validați o frunză astfel:

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

Țineți cheia de semnare în spatele unei granițe de politici în loc să o copiați pe hostul VPN: un serviciu mic care autentifică cererea, verifică numele comun împotriva unei liste de permisiuni și returnează doar certificatul. Înregistrați fiecare număr de serie; jurnalul este singura legătură dintre un certificat și persoana care l-a cerut.

Publicați revocarea fără a trezi rădăcina

Certificatele clienților sunt revocate de intermediar, niciodată de rădăcină. Lista rădăcină contează doar când un intermediar este ars. Îndreptați serverul spre lista intermediară cu crl-verify. Un CRL bazat pe fișier este încărcat la pornirea serviciului, așa că reîncărcați-l după fiecare regenerare; forma de director citește starea la momentul conectării și costă un fișier per număr de serie.

Revocați și regenerați cu două comenzi din aceeași bază de date:

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

Apoi urmăriți ceasul. Un CRL poartă un câmp de următoare actualizare, iar când acea dată trece, un partener care validează respinge lista în loc să o ignore. Regenerarea lunară cu default_crl_days = 30 lasă marjă; cea anuală nu. Durate de viață mai scurte ale frunzelor sunt controlul mai fiabil, deoarece revocarea se aplică doar acolo unde lista este consultată.

Testați lanțul, apoi scrieți ceremonia

Reproduceți patru eșecuri înainte de a avea încredere în proiect. Validați lanțul cu openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Conectați-vă cu un certificat de client expirat și confirmați că serverul îl respinge. Revocați un client de test, reîncărcați și confirmați că lista intră în vigoare. Dați ceasul unui host cu o zi înainte, deoarece un ceas greșit poate emite și respinge certificate care par valide în altă parte.

O rădăcină offline este un control doar dacă există actele: două persoane numite pentru ceremonie, o evidență a fiecărui număr de serie semnat, o copie de siguranță criptată păstrată separat de mașină și un test de restaurare pe un host izolat. Semnați un intermediar de rezervă în timpul aceleiași ceremonii, astfel încât un host de semnare mort să nu vă oblige să deblocați rădăcina la miezul nopții.

Înainte de a-l numi terminat, confirmați cinci lucruri: cheia rădăcină nu este pe un host în rețea, cheia intermediară trăiește doar pe hostul de semnare, pachetul clientului poartă ambele certificate CA, CRL-ul are o următoare actualizare în viitor și cineva deține o intrare în calendar pentru fiecare expirare din lanț. Dacă lipsește una, configurația care pare offline este doar nedocumentată.