Ce verifică clientul tău VPN înainte de a avea încredere într-un certificat

Clientul tău VPN spune că certificatul nu a putut fi verificat, iar dialogul se oprește acolo. Fișierul există, serverul funcționează, iar același profil a funcționat pe alt laptop luna trecută. Sub acel avertisment de o singură linie, clientul a trecut certificatul perechii prin patru porți: o autoritate de certificare pe care ai configurat-o garantează calea semnăturii, acea cale ajunge la autoritate, numele perechii este cel pe care l-ai cerut, iar certificatul este utilizabil acum pentru acest scop. Găsește poarta care s-a închis, iar reparația este de obicei un fișier; sari peste acel pas și vei reimporta pachete toată după-amiaza.

Citește dialogul înainte de a edita profilul

Erorile de certificat sunt formulate de biblioteca de dedesubt, nu de produsul VPN pe care l-ai instalat, așa că șirul exact este prima ta dovadă. „Nu se poate obține certificatul emitentului local” indică calea sau ancora de încredere. „Certificatul a expirat sau încă nu este valid” indică timpul. „Scop al certificatului neacceptat” indică utilizarea extinsă a cheii. O nepotrivire de nume îți spune ce nume se dorea. Niciuna dintre cele patru nu se repară prin reinstalarea clientului.

Crește nivelul de jurnalizare înainte de a schimba ceva. OpenVPN raportează eșecul verificării în jurul strângerii de mână când îl rulezi cu --verb 4, iar strongSwan își scrie deciziile de identitate și lanț în jurnalul charon. Apoi confirmă ce certificat inspectezi, pentru că oamenii testează de obicei fișierul de pe disc în timp ce profilul încorporează o copie mai veche. Când profilul încorporează blocuri PEM, certificatul încorporat este cel testat.

O autoritate de certificare semnează identități, nu permisiuni

Autoritatea deține un nume și o cheie de semnare. Ea emite certificate care leagă o cheie publică de acel nume conform propriei politici, cu o fereastră de valabilitate și restricții de utilizare atașate. Clientul tău are nevoie doar de certificatul autorității pentru a recunoaște emitentul; nu are niciodată nevoie de cheia de semnare, iar trimiterea acelei chei către clienți le-ar da capacitatea de a fabrica orice identitate în care are încredere implementarea.

Încrederea într-o autoritate face fiecare certificat pe care l-a semnat un candidat, nu perechea potrivită. Un certificat de server web din aceeași CA internă este și el un candidat. De aceea există porțile de nume și scop și de aceea o cheie CA compromisă contează mai mult decât orice server individual: ajunge la fiecare identitate pe care autoritatea a emis-o vreodată. Emite certificate de client pentru fiecare dispozitiv, astfel încât un laptop pierdut să fie o singură revocare, nu o regenerare de chei pentru întreaga implementare.

Reconstruiește calea pe care clientul încearcă să o construiască

Calea merge de la certificatul perechii, prin zero sau mai multe certificate intermediare, până la o rădăcină din magazinul tău de încredere. Un intermediar lipsă este cea mai frecventă defecțiune de lanț, iar din partea clientului arată identic cu o rădăcină neîncrezută. Citește mai întâi frunza, apoi lasă OpenSSL să construiască calea din materialul pe care intenționezi să-l trimiți.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Starea de ieșire zero înseamnă că calea a fost construită din acele fișiere; un eșec numește certificatul la care nu s-a putut ajunge. Dacă openssl verify reușește în timp ce clientul încă refuză, diferența este în ce trimite serverul efectiv sau în ce fișier de încredere încarcă profilul. În OpenVPN, intermediarele pot călători cu fișierul certificatului serverului sau pot fi furnizate separat cu --extra-certs, iar un pachet cu două rădăcini scrise sub același nume de subiect va trimite unul dintre clienții tăi pe ramura greșită.

Numele și scopul sunt porți separate

Construirea lanțului nu întreabă niciodată dacă numele este al tău. OpenVPN îl verifică doar când profilul setează --verify-x509-name, iar obiceiul mai vechi de a potrivi doar numele comun se rupe la certificatele ale căror identități trăiesc în subjectAltName. Implementările IKEv2 potrivesc identitatea configurată cu intrările SAN sau cu numele distinctiv, în funcție de client, iar o valoare wildcard sau %any dezactivează în tăcere comparația pe care credeai că o ai.

Urmează timpul și scopul. Un laptop al cărui ceas merge cu câteva ore înainte respinge un certificat încă nevalid, iar un intermediar expirat face calea să eșueze în timp ce frunza este valabilă. Eșecurile de scop provin dintr-un certificat fără serverAuth în utilizarea extinsă a cheii, sau cu un keyUsage care nu permite semnătura strângerii de mână, pe care OpenSSL îl raportează ca scop de certificat neacceptat. Reemite din șablonul corect; nimic din acel mesaj nu este motiv să dezactivezi verificarea.

Revocarea rulează doar dacă cineva a configurat-o

O CRL sau un răspuns OCSP nu sunt consultate automat. Pe un server OpenVPN, certificatele de client sunt comparate cu o listă doar când --crl-verify indică una. Verificarea certificatului serverului din partea clientului depinde de implementare și deseori lipsește. strongSwan are nevoie de pluginul său de revocare și de o politică înainte de a se uita la o CRL pentru o pereche.

Asta explică tichetul pe care îl vei primi în final: un certificat de client revocat se conectează în continuare, iar toți concluzionează că revocarea este stricată. Nimic nu verifica. Publică și reîmprospătează CRL-ul, sau ține certificatele de client suficient de efemere încât o revocare învechită să conteze puțin timp, și exersează calea de revocare pe un certificat de laborator înainte de a avea nevoie de ea în timpul unui incident.

O ordine de reparare care ține verificarea pornită

Sortează după simptom înainte de a atinge fișiere, pentru că fiecare rând al tabelului te trimite la un obiect diferit.

Parcurge lista într-o singură trecere: confirmă fișierul pe care îl încarcă profilul, construiește calea singur, verifică dacă serverul trimite intermediarul, compară ceasul, citește SAN-ul, citește EKU-ul, apoi reconectează-te și urmărește cum dispare aceeași linie de jurnal. Dacă unui dispozitiv nu i se poate da deloc o CA, fixarea prin pinning este alternativa onestă, pentru că OpenVPN 2.6 acceptă --peer-fingerprint și îngustează încrederea la o singură cheie în loc să elimine verificarea. RFC 5280 este referința pentru ce înseamnă fiecare dintre acele câmpuri.