Reînnoirea unui certificat VPN fără a-i schimba identitatea

O reînnoire de certificat care schimbă identitatea nu este o reînnoire, este o migrare îmbrăcată într-un tichet de mentenanță. Clientul verifică un nume, un lanț și uneori o cheie anume, iar toate trei se pot schimba fără ca data de expirare să se schimbe. Înainte de a cere o înlocuire, notați ce verifică de fapt clientul: numele gazdă sau identitatea partenerului, scopul certificatului, politica de chei și lanțul emitent. Reînnoirea este de rutină sau coordonată în funcție de ceea ce schimbă înlocuirea.

Trei condiții decid forma reînnoirii

Cele trei condiții sunt dacă ceva fixează frunza, dacă se schimbă lanțul și cine mai validează numele. Răspundeți din partea clientului, nu din comoditatea CA, pentru că clientul este cel care eșuează la ora trei dimineața.

Începeți prin a inspecta certificatul pe care îl aveți. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName afișează subiectul, emitentul, fereastra de valabilitate și numele pentru care certificatul este cu adevărat valabil. Ultimul câmp este cel mai important și cel mai des presupus: o cerere de reînnoire care omite un SAN pe care clientul se bazează produce un certificat tehnic valabil, dar funcțional greșit. Copiați lista SAN din certificatul vechi în cerere, în loc să o retastați din memorie.

Condiția unu: ceva fixează frunza

Dacă clienții au încredere într-o CA întreținută și validează numele, o reînnoire de frunză cu o cheie nouă este invizibilă pentru ei. Dacă vreun client fixează certificatul de frunză, amprenta lui sau cheia lui publică, înlocuirea este o schimbare coordonată cu o tranziție dură, pentru că fixarea veche nu poate valida certificatul nou.

Aflați în ce caz vă aflați înainte de a comanda ceva. O fixare pe care nimeni nu a documentat-o rămâne o fixare atunci când se rupe.

Condiția doi: comparați fixările și lanțul

Amprentele fac fixarea verificabilă: openssl x509 -noout -fingerprint -sha256 -in server.crt pe certificatul vechi și pe cel nou, și openssl x509 -noout -pubkey pentru a compara cheile publice. Dacă configurația clientului, un profil mobil sau un depozit de încredere al unui aparat conține vreuna dintre valori, aveți o fixare. Profilele VPN mobile sunt o ascunzătoare obișnuită, pentru că profilul este distribuit o dată și niciodată inspectat din nou.

Dacă înlocuirea vine de la același intermediar și clientul îl are deja sau îl poate obține, nimic nu se schimbă pe partea de încredere. Un intermediar nou, un emitent diferit sau un lanț livrat în ordinea greșită transformă o reînnoire într-o schimbare de încredere, iar eșecul arată ca un emitent necunoscut, nu ca un certificat expirat.

Verificați lanțul pe care serverul îl trimite de fapt cu openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, și validați-l local cu openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. A face asta înainte de schimbare vă oferă o linie de bază pentru comparația de după.

Condiția trei: cine mai validează numele

Un concentrator VPN, un balanceator de încărcare, o sondă de monitorizare, o integrare RADIUS sau SAML și un profil mobil pot ține fiecare propria copie a numelui așteptat sau a ancorei de încredere. Reînnoirea este momentul în care acele copii diverg, pentru că certificatul se schimbă, iar copiile nu.

Enumerați fiecare consumator înainte de schimbare și decideți, pentru fiecare, dacă are nevoie de o actualizare. Cel pe care îl uitați este cel care vă sună.

Există și o capcană de timp. Inspectați începutul valabilității precum și expirarea, pentru că un certificat pregătit pentru activare ulterioară este respins dacă este instalat prea devreme, iar eroarea arată ca o problemă de ceas, nu ca o problemă de pregătire. openssl x509 -noout -dates pe fișierul nou înainte de a-l implementa este o verificare de două secunde. Păstrați și o cale de recuperare acceptată și configurația cunoscută ca bună, astfel încât o reînnoire care merge prost să fie reversibilă prin restaurarea certificatului și a cheii anterioare.

Implementați, verificați cu o autentificare nouă, apoi retrageți

Un tunel stabilit reflectă validarea care a avut loc când a fost construit, așa că poate părea sănătos în timp ce fiecare conexiune nouă eșuează. Testați cu o autentificare nouă folosind numele de serviciu real pe care îl folosesc clienții.

Finalizați verificarea la nivel de aplicație care contează pentru utilizator și confirmați livrarea lanțului din perspectiva clientului, nu a serverului. Nu suprimați verificările de nume sau de certificat pentru a păstra tranziția silențioasă; asta transformă o problemă temporară de compatibilitate într-una permanentă.

Retrageți materialul învechit numai după ce implementarea este verificată, și tratați o cheie compromisă ca pe un caz complet diferit: reînnoirea singură nu revocă nimic, așa că identitatea afectată are nevoie de procesul de revocare și de gestionare a sesiunilor al implementării. RFC 5280 definește regulile de certificat și de validare a căii aflate sub toate acestea. Țineți o reînnoire de frunză de rutină separată de o înlocuire de CA, astfel încât clienții să nu fie rugați să aibă încredere într-un emitent nou fără motiv.