Două certificate OpenVPN, un singur nume CCD: ce a mers greșit
Un număr de serie este unic doar în cadrul emitentului său, în timp ce OpenVPN alege fișierul CCD după nume. Rezervați acel nume efectiv la înscriere și controlați reînnoirea.
Două certificate de client cu numere de serie diferite, chei diferite și chiar subiecte complete diferite pot ajunge totuși în același fișier de politică, pentru că serverul nu se uită la nimic din toate acestea. Citește un nume din certificat și deschide fișierul de configurare al clientului corespunzător. Dacă ambele certificate poartă același nume, al doilea moștenește politica primului în momentul în care se conectează.
Coliziunea este creată la înscriere și este descoperită doar la conectare, de obicei când un dispozitiv primește o adresă sau un set de rute care aparțin altei mașini. Prevenirea ei înseamnă să conveniți asupra câmpului pe care îl mapează serverul și apoi să rezervați acea valoare înainte de a se semna ceva.
Instrumentele dumneavoastră pentru certificate nu vă vor avertiza, pentru că unicitatea în interiorul X.509 și unicitatea unui nume de politică OpenVPN sunt cerințe diferite aplicate de sisteme diferite.
Serverul caută un nume, nu o amprentă
La maparea obișnuită bazată pe certificate, serverul ia numele comun din certificatul prezentat și caută un fișier cu acel nume în directorul său de configurare a clienților. Acel fișier poate fixa o adresă statică, poate împinge rute sau poate aplica marcaje de firewall pentru fiecare client. Căutarea este o potrivire de șir cu un nume de fișier, așa că majusculele, spațiile și punctuația contează toate.
Unele implementări inversează intenționat maparea, astfel încât un nume de utilizator autentificat să preia numele comun, iar atunci numele de utilizator este cel care trebuie să fie unic. În orice caz, valoarea care selectează politica este valoarea pe care o rezervați. Decideți care este înainte de a emite ceva; a ghici după o coliziune costă mai mult decât a întreba.
Unde două autorități se întâlnesc pe același nume
O organizație care acceptă certificate de la mai mult de o autoritate emitentă rulează două procese de înscriere independente care scriu într-un singur spațiu de nume. Regulile proprii de unicitate ale fiecărei autorități se aplică în interiorul ei, așa că ambele pot emite legitim pentru același nume comun fără ca vreuna să observe ceva greșit.
Numerele de serie nu ajută. X.509 cere ca un număr de serie să fie unic în sfera emitentului său, ceea ce este o proprietate a contabilității acelei autorități, nu o identitate globală a dispozitivului. Verificarea subiectului este și un test diferit de verificarea numelui comun: două certificate pot împărtăși un CN, dar pot diferi în unitatea organizațională și, prin urmare, purta subiecte distincte. Toate aceste proprietăți pot fi valabile în timp ce serverul mapează în continuare ambele certificate la un singur nume de fișier.
Documentația OpenSSL CA acoperă setarea unique_subject care guvernează părerea propriei baze de date, iar punctul de plecare onest este să citiți configurația dumneavoastră de emitere în loc să presupuneți că se aplică o anumită valoare implicită EasyRSA sau OpenSSL.
Rezervați numele efectiv înainte de semnare
Țineți un registru care mapează un dispozitiv la înregistrarea sa aprobată și de acolo la un nume exact de fișier de politică, astfel încât un nume să fie alocat o singură dată și să rămână alocat. Rezervarea trebuie să fie atomică, ceea ce în practică înseamnă o constrângere de bază de date sau o blocare în jurul pasului alocă-apoi-semnează, nu o foaie de calcul editată de două persoane.
Apoi faceți verificarea parte din emitere: refuzați să semnați când numele solicitat există deja și includeți în acea verificare fiecare autoritate în care serverul are încredere, pentru că un nume rezervat de cealaltă autoritate este la fel de ocupat. O cerere respinsă cu un motiv clar costă mai puțin decât un tichet despre un dispozitiv care primește mereu adresa statică a altcuiva.
Reînnoirea reutilizează un nume intenționat
Reemiterea pentru un dispozitiv existent ar trebui să producă un număr de serie nou sub același nume de politică, iar aceasta este o reutilizare legitimă și nu o coliziune. Ceea ce trebuie decis dinainte este suprapunerea: dacă certificatul vechi și cel nou pot fi valabile simultan și cum este retrasă acreditarea veche.
Nu apelați la duplicate-cn pentru a rezolva acest lucru. Această opțiune a serverului guvernează conexiunile simultane care prezintă același nume; nu blochează înscrierea, iar activarea ei nu face o adresă statică partajată sigură pentru două mașini simultan. Revocarea identifică de obicei un certificat după emitent și număr de serie, așa că retragerea acreditării vechi nu trebuie să invalideze înlocuitorul ei atâta timp cât serverul primește și aplică datele corecte de revocare.
Confirmați maparea cu instrumentele de pe mașină
Înainte de a da unui dispozitiv noua sa acreditare, citiți numele din certificat așa cum va face serverul și apoi comparați-l cu fișierul de politică pe care vă așteptați să fie ales.
openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf
Prima comandă afișează câmpurile subiectului separat, ceea ce face vizibilă imediat o unitate organizațională rătăcită sau un spațiu dublu. A doua confirmă că există un fișier de politică exact sub acel nume, iar a treia arată dacă serverul este configurat să permită mai multe sesiuni pe un singur nume. Rulați toate trei pe un certificat nou înainte ca acesta să părăsească pasul de înscriere, cât timp o greșeală costă încă o semnătură și nu un incident. Păstrați rezultatul împreună cu tichetul, astfel încât următoarea persoană să vadă ce nume a primit de fapt serverul.
Încheiați cu o conexiune reală și comparați adresa atribuită și rutele împinse cu fișierul de politică, și nu cu ceea ce intenționați să scrieți. Dacă două dispozitive raportează aceeași adresă statică, registrul are o coliziune pe care nicio inspecție de certificate nu o va dezvălui vreodată.