OpenVPN verify-x509-name: subject, name și name-prefix

Citiți mai întâi tipul de potrivire și apoi textul: o verify-x509-name directivă poate părea corectă și totuși să accepte un certificat în care nu intenționați să aveți încredere. Două linii cu același text așteptat, dar tipuri diferite sunt cerințe diferite. Citiți mai întâi tipul, apoi textul. Tratați directiva ca pe o condiție suplimentară a conexiunii, nu ca pe întreaga verificare.

Ce afirmă de fapt opțiunea

Directiva numește o identitate pe care certificatul celeilalte părți trebuie să o poarte. Când comparația eșuează, OpenVPN întrerupe strângerea de mână și niciun tunel nu se ridică. Tot restul din profil se aplică în continuare: certificatul trebuie să se înlănțuie la o CA de încredere, iar verificarea rolului trebuie să treacă, deci aceasta este o condiție suplimentară, nu un substitut. Un profil care satisface așteptarea numelui și eșuează verificarea rolului rămâne stricat, iar jurnalul spune de obicei acest lucru.

Diferă și de validarea numelui de gazdă pe care o face un browser. Browserul potrivește numele cu numele alternative ale subject după regulile stivei sale TLS, în timp ce OpenVPN compară un singur câmp al certificatului cu tipul ales de dumneavoastră. De aceea lipirea unui nume de gazdă în stil browser în directivă poate produce o nepotrivire chiar și atunci când certificatul acoperă într-adevăr serviciul.

subject: numele distinctiv complet, caracter cu caracter

Când nu este scris niciun tip, implicit este subject, iar valoarea așteptată trebuie să reproducă întregul subject DN al certificatului. Ordinea câmpurilor, separatoarele, spațiile și escaping-ul contează toate, deoarece comparația rulează pe șirul așa cum este codificat. Dacă omiteți tipul, ați ales cea mai strictă dintre cele trei comparații. Nu există niciun pas de normalizare care să salveze o diferență cosmetică. Merită să știți asta înainte de prima reînnoire, nu după.

Acea strictețe este fragilă între reînnoiri. O CA care reordonează atributele, inserează un câmp suplimentar sau schimbă modul în care face escaping unei valori produce un șir nou pentru aceeași mașină, iar o directivă care a funcționat ani de zile începe să eșueze la următoarea emitere. Păstrarea DN-ului acceptat în jurnalul modificărilor transformă următoarea reînnoire într-o diferență. Acolo unde operatorul publică un DN complet și garantează forma acestuia, subject este o alegere rezonabilă; în alte părți, un câmp mai îngust este mai ușor de menținut adevărat.

name: un singur câmp, de obicei numele comun

Tipul name compară un singur câmp al subject. Dacă profilul nu spune altfel, acel câmp este numele comun, iar valoarea așteptată este exact acel câmp, nu DN-ul din jurul lui.

Capcana este că certificatele moderne nu pun întotdeauna numele serviciului în CN. Multe îl poartă într-un nume alternativ al subject și lasă CN-ul gol sau generic, așa că un certificat pe care un browser îl acceptă poate totuși eșua această comparație. Inspectați certificatul care v-a fost efectiv emis înainte de a scrie așteptarea și confirmați ce câmp selectează profilul. Un CN gol comparat cu un nume este o nepotrivire, nu un accident de configurare.

name-prefix: larg prin concepție, deci delimitați-l

O așteptare de tipul name-prefix corespunde începutului câmpului selectat. Este comod pentru o schemă de denumire și periculos pentru orice este partajat.

Cu vpn.example ca așteptare, atât vpn.example.com cât și vpn.example.net ar trece, cu condiția ca restul lanțului să fie de încredere. Amploarea este funcția și totodată partea care trebuie justificată în scris. Un prefix este rezonabil când CA-ul și schema de denumire sunt ale dumneavoastră, și mult mai slab când o CA publică emite în același model. Dacă schema are nevoie de flexibilitate, limitați-o la CA în loc să lărgiți verificarea clientului.

Alegeți tipul după identificator, apoi dovediți-l

Lucrați invers de la identitatea pe care operatorul o intenționează. Dacă publică un DN complet și îl menține stabil, subject exprimă acest lucru. Dacă numește serviciul după numele comun, folosiți name. Dacă deține o schemă de denumire și acceptă tot spațiul ei, name-prefix spune asta explicit.

Reînnoirile sunt locul unde directiva este testată. Comparați identitatea aprobată cu certificatul nou, nu cu fișierul vechi, deoarece o adresă nouă de punct final nu implică o identitate nouă a certificatului. Nu ștergeți directiva doar pentru că răspunde o adresă cunoscută: accesibilitatea și cealaltă parte intenționată sunt fapte diferite, iar adresa dovedește doar că ceva a răspuns. Notați eroarea exactă și detaliile publice ale numelui într-un raport curățat, deoarece o nepotrivire de nume poate fi arătată fără niciun material de cheie privată.

După o corectare acceptată, reconectați-vă cu toate verificările intenționate active și verificați resursa de care aveți cu adevărat nevoie. Succesul înseamnă că serverul intenționat a fost acceptat, nu că un certificat a fost forțat să treacă. Manualul oficial OpenVPN 2.6 manual documentează cele trei tipuri și notele lor de încredere, și este referința de citat atunci când o interfață a unui furnizor nu este de acord cu profilul.