remote-cert-tls server: ce verifică într-un profil OpenVPN

Trei întrebări diferite primesc răspuns de la trei părți diferite ale unui profil OpenVPN, iar combinarea lor este modul în care oamenii ajung să dezactiveze o verificare care funcționa. Certificatul celuilalt capăt este semnat de autoritatea în care am încredere? Acel certificat declară rolul de server TLS? Este exact serverul la care voiam să ajung? remote-cert-tls server răspunde doar la întrebarea din mijloc, și o face citind extensiile din interiorul certificatului.

Trei verificări ușor de combinat în minte

Ancora de încredere se află în directiva ca. Verificarea rolului aparține directivei remote-cert-tls. Verificarea identității aparține directivei verify-x509-name, când un profil o folosește, sau oricărei verificări de nume adăugate de implementare.

Acoperă eșecuri diferite:

Un profil poate avea toate trei și poate rămâne slab dacă CA este partajată prea larg, ceea ce este o problemă de gestionare a cheilor, nu de directivă.

Ce citește verificarea rolului

Directiva este o macrocomandă. Se extinde într-o cerință de utilizare a cheii și o cerință de utilizare extinsă a cheii care numește rolul de server web TLS, deci certificatul celuilalt capăt trebuie să declare efectiv acest scop. Un certificat emis pentru autentificarea clientului nu o satisface, chiar și atunci când aceeași autoritate le-a semnat pe amândouă.

Acest lucru contează pentru că o CA partajată este obișnuită în implementările mici. O autoritate semnează fiecare client și serverul, iar fără o verificare a rolului oricare dintre acele certificate ar putea finaliza partea de server a strângerii de mână. Verificarea nu face acel scenariu imposibil, dar elimină versiunea lui trivială.

Directiva este asimetrică prin proiectare: clienții poartă remote-cert-tls server, iar serverele poartă remote-cert-tls client. Schimbați-le și fiecare conexiune eșuează cu o eroare de rol care arată ca un certificat stricat.

Profilurile mai vechi folosesc uneori ns-cert-type în același scop. Paginile de manual actuale tratează acea opțiune ca înlocuită, așa că un profil care încă se bazează pe ea merită migrat, nu depanat.

De ce dezactivarea pare o soluție

Când verificarea rolului eșuează, conexiunea se oprește cu o eroare de verificare, iar mișcarea evidentă este ștergerea liniei. Conexiunea apare apoi, ceea ce pare progres și este de fapt modul de eșec pe care directiva există să îl prevină. Acum acceptați un celălalt capăt al cărui certificat nu a fost niciodată destinat acelui rol.

Citiți în schimb eroarea. Ea numește verificarea care a eșuat, iar certificatul de cealaltă parte poate fi inspectat pentru a vedea ce extensii poartă de fapt. Două minute de citire stabilesc dacă problema este în emitere sau în configurație. Ghiceala costă o după-amiază și se termină de obicei cu un profil slăbit. Un certificat de server reînnoit care și-a pierdut utilizarea extinsă a cheii este o eroare reală la reînnoire, nu un motiv de a relaxa clientul.

Verificarea numelui este o directivă separată

Satisfacerea verificării rolului spune că celălalt capăt este un anumit server semnat de autoritatea dumneavoastră. Nu spune care, ceea ce contează când aceeași CA emite certificate pentru mai multe gateway-uri și unul dintre ele este compromis sau reutilizat.

verify-x509-name compară subiectul certificatului cu o valoare pe care o configurați, cu moduri de potrivire pentru un subiect exact, un prefix sau un singur câmp. Folosiți câmpul care identifică efectiv gateway-ul și așteptați-vă să îl actualizați deliberat când se schimbă numele.

Niciuna dintre directive nu înlocuiește o bună manipulare a cheilor. Dacă fișierul cheii clientului este copiat în jur împreună cu profilul, identitatea celuilalt capăt este doar atât de puternică pe cât este lista de distribuție.

Inspectați certificatul înainte de a edita profilul

Citiți certificatul celuilalt capăt și jurnalul clientului, în această ordine. Certificatul vă spune ce roluri declară; jurnalul vă spune care verificare l-a respins.

Aceste comenzi afișează extensiile de utilizare și liniile de verificare dintr-o conexiune detaliată:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Dacă extensiile arată rolul de server și jurnalul raportează în continuare o eroare de rol, profilul indică probabil fișierul de certificat greșit, nu un certificat prost. Dacă extensiile arată doar autentificare client, opriți-vă din a privi clientul și corectați emiterea. În orice caz, restabiliți verificarea înainte de a declara conexiunea sănătoasă, pentru că o strângere de mână reușită după eliminarea verificării demonstrează mai puțin decât eroarea pe care a înlocuit-o.