Folosiți CA-ul de întreprindere existent pentru omologii OpenVPN

Nimic din OpenVPN nu cere ca certificatul să vină de la Easy-RSA, iar o flotă care are deja o PKI organizațională de obicei nu ar trebui să construiască una a doua. Munca reală nu este alegerea unui instrument, ci deciderea a ceea ce înseamnă identitățile emise, ce omologi acceptă tunelul și cum ajung reînnoirea și revocarea la verificator. Parcurgeți pașii cinci de mai jos în ordine, deoarece un pas ulterior nu poate repara o decizie privind rolul luată în primul.

Emiteți două roluri în loc de o singură identitate partajată

Fiecare omolog are nevoie de propriul certificat și de cheia privată corespunzătoare. Cereți echipei PKI o identitate de server cu utilizare de server și identități de client separate cu utilizare de client, astfel încât tunelul să le poată distinge în timpul strângerii de mână.

Rezistați scurtăturilor care apar sub presiunea termenelor. O cheie de server web copiată pe laptopuri șterge distincția pe care se bazează verificarea rolului, iar o cheie de semnare CA instalată pe un punct final VPN transformă un singur gazdă compromisă într-o ierarhie compromisă. Un pachet PKCS12 poate transporta o cheie de punct final și lanțul ei, dar nu acordă niciodată permisiunea de a reutiliza acea identitate într-un alt rol.

Conectați intrările de încredere pe fiecare parte

Clientul și serverul au nevoie fiecare de o ancoră de încredere, de propria identitate și de o așteptare explicită privind rolul. Un fragment de client care enumera toate trei arată astfel.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Partea de server o oglindește cu remote-cert-tls client și cu propriul certificat, și exact aceasta împiedică acceptarea unui certificat de client drept server. Verificarea numelui este o decizie separată de verificarea rolului. Citiți configurația implementată pentru a vedea ce câmp este comparat, în loc să presupuneți o potrivire de nume de gazdă în stilul browserului. Ambele părți ar trebui, de asemenea, să fie explicite cu privire la emitentul în care au încredere, deoarece o cale de fișier partajată în întreaga flotă nu este același lucru cu o politică partajată.

Livrați certificatele intermediare fără a lărgi încrederea

Cele două părți nu trebuie să împartă un singur lanț de emitere. Când un omolog prezintă un certificat semnat de un intermediar, partea care verifică are nevoie de acel intermediar disponibil, și OpenVPN distinge intrarea ancorei de încredere de certificatele suplimentare folosite pentru a completa un lanț prezentat local. Referința opțiunilor TLS din OpenVPN 2.6 documentează ambele.

Un CA intermediar nu este în sine o problemă, dar o rădăcină de întreprindere largă aruncată în pachetul de încredere este. Cu cât ancora este mai largă, cu atât mai multe certificate trec testul lanțului, iar o verificare a rolului nu transformă asta într-o listă de personal autorizat. Îngustați ancora la emitentul care semnează efectiv identitățile VPN acolo unde ierarhia permite. Dacă nu permite, documentați ancora mai largă ca risc acceptat în mod deliberat, în loc să o lăsați implicită.

Conveniți cu echipa PKI asupra modului în care reînnoirea și revocarea ajung la verificatorii VPN, inclusiv ce emitenți contează și cine publică lista. Un punct de distribuție CRL încorporat într-un certificat este o instrucțiune, nu o dovadă că ceva l-a preluat.

Decideți cum ajunge de fapt revocarea

crl-verify face ca verificatorul să consulte un fișier sau un punct final, iar acest aranjament are nevoie de un proprietar și de o cale de actualizare. O listă copiată o singură dată în timpul implementării încetează în mod silențios să vă protejeze la prima revocare a unui certificat.

Notați timpul de propagare așteptat și testați-l cu un certificat pe care sunteți dispus să îl revocați. Dacă lista nu poate fi actualizată pe gazda VPN, alternativa este o perioadă de valabilitate mai scurtă plus un proces de reînnoire care chiar rulează, nu presupunerea că revocarea funcționează pentru că există un URL.

Demonstrați acceptarea cu un client real

Conectați un client care ar trebui să fie permis și confirmați în jurnal detaliile certificatului negociat. Apoi încercați cazurile care trebuie să eșueze: un certificat de client prezentat ca server, un certificat de la un emitent din afara ancorei de încredere și un certificat revocat dacă aveți unul în plus.

Înregistrați emitentul acceptat, verificarea rolului și sursa revocării lângă profil. Acea înregistrare este ceea ce are nevoie următorul inginer atunci când un dispozitiv care funcționa luna trecută nu se mai conectează, și este și dovada că CA-ul de întreprindere este folosit într-o limită de acceptare documentată, nu ca o haldă de încredere de uz general.