Certificat VPN reînnoit: unii clienți încă îl resping

Jumătate din mediu se reconectează după reînnoire, iar trei dispozitive refuză, fiecare cu un avertisment despre identitatea gateway-ului. Reînnoirea în sine este de rutină. Ce păstrează acele trei dispozitive este o fixare pe obiectul vechi, iar o fixare nu este o listă de CA, o verificare a numelui sau o intrare în depozitul de încredere. Comparați cele trei mecanisme înainte de a atinge orice client.

O reînnoire, două comportamente

Clienții care se reconectează au o decizie de încredere care încă trece, iar cei care refuză au o cerință pe care certificatul nou nu o îndeplinește. Această diferență este informație, nu zgomot. Citiți cu precizie mesajul clientului care eșuează. O nepotrivire de nume, un emitent necunoscut și o amprentă schimbată sunt trei verdicte diferite, iar doar ultimul indică o fixare.

Verificați și ce profil a ales clientul care eșuează. O copie importată care trăiește în propriul depozit nu se schimbă când administratorul editează fișierul original în altă parte.

Reînnoirea înlocuiește obiectul, nu doar data

O amprentă identifică conținutul codificat al certificatului. Reînnoirea produce un certificat nou, deci amprenta se schimbă chiar și când numele subiectului și cheia publică rămân identice. Acest lucru este așteptat și inofensiv pentru clienții care au încredere într-o CA și verifică numele. Este fatal pentru un client configurat să accepte exact un certificat, și este fatal și pentru un client al cărui depozit de încredere nu a primit niciodată noul emitent.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

A doua linie răspunde la altă întrebare, dacă perechea de chei a supraviețuit. O reînnoire care refolosește cheia păstrează acea valoare și schimbă doar certificatul, și exact acesta este cazul în care administratorul este tentat să presupună că nimic nu s-a schimbat. Inspectați certificatul care este implementat, nu cel de pe gazda de build. Compararea unui fișier dintr-un depozit demonstrează ce a fost generat, nu ce prezintă în acest moment un listener.

Citiți ce fixează clientul

Unii clienți păstrează o amprentă în profilul lor și o compară la fiecare conexiune. Alții o stochează într-un depozit de încredere al platformei, iar alții se bazează doar pe o CA. Reparația diferă în fiecare caz, așa că identificați mai întâi mecanismul.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Prima comandă arată o fixare într-un profil convențional; a doua arată amprenta pe care endpoint-ul o servește chiar acum. Când cele două diferă, ați localizat defectul fără să ghiciți. Nu lipiți noua valoare în fiecare client care se plânge. Un client care refuză din motive de emitent va continua să refuze, iar dumneavoastră v-ați convins singur că amprenta era problema când nu era.

Comparați certificatul servit de fiecare backend

Rezultatele intermitente înseamnă de obicei mai mult de un endpoint, iar o reînnoire aplicată pe un singur nod lasă celelalte să prezinte obiectul vechi. Comparați fiecare backend după adresă și nu după numele comun.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Un pool în care un nod rămâne în urmă explică un client care se conectează la a doua încercare și eșuează la prima. Explică și o verificare de monitorizare care trece în timp ce utilizatorii se plâng. Remediați mai întâi decalajul. Derularea configurației de încredere înainte ca fiecare nod să servească certificatul nou creează o fereastră în care nimic nu funcționează, iar derularea de după lasă clienții să eșueze imprevizibil.

Schimbați încrederea pe calea gestionată

Confirmați înlocuirea printr-un canal administrativ deja de încredere înainte de a o accepta oriunde. O dată de expirare plauzibilă nu este dovadă de proprietate. Actualizați configurația gestionată prin procesul care o deține, cu orice suprapunere planificată de identități acceptabile, și păstrați verificarea numelui cerută de implementare. O fixare fără verificarea numelui este un design mai slab decât încrederea în CA pe care a înlocuit-o.

Apoi verificați pentru fiecare client, conectați-vă, confirmați identitatea pe care a acceptat-o și notați versiunea certificatului în care are acum încredere. Un avertisment ignorat o dată are obiceiul să revină la următoarea reînnoire.