Cum elimini un certificat VPN învechit dintr-un magazin de încredere

Clientul VPN este dezinstalat, profilul a dispărut din Setări, iar tunelul tot se ridică cu acreditările vechi. Ori îl ștergi, repornești și îl găsești înapoi a doua zi dimineață. Niciuna dintre situații nu înseamnă un buton de ștergere defect. Un profil este configurație; un certificat este material de cheie plus o decizie de încredere înregistrată într-un magazin spre care profilul doar indică. Pe care dintre cele două îl ții în mână decide ce trebuie să însemne 'elimină'.

Un profil nu este un certificat

Într-o configurație VPN, trei obiecte diferite sunt numite 'certificatul'. Identitatea clientului este un certificat frunză cu o cheie privată, iar gateway-ul îl folosește ca să decidă cine ești. Certificatul frunză al serverului însuși și intermediarul său sunt ceea ce clientul tău verifică atunci când se conectează. Ancora de încredere, de obicei un certificat rădăcină sau de CA privată, este ceea ce face lanțul verificabil. RFC 5280 le numește ancora de încredere, intermediarul și entitatea finală, iar lanțul se validează doar cât timp fiecare verigă o semnează pe cea de dedesubt.

Șterge identitatea și un dispozitiv pierde accesul. Șterge ancora și fiecare aplicație care validează față de acel magazin pierde capacitatea de a verifica orice emis sub ea, inclusiv conexiuni care nu au nimic de-a face cu VPN-ul. Această asimetrie este întregul risc aici: o rădăcină instalată pentru un gateway este adesea aceeași rădăcină care semnează un portal intern, un server de e-mail sau o oglindă de pachete. Ține minte pe care dintre cele două o ai în mână.

Proprietatea decide dacă ștergerea rămâne ștearsă. Pe un laptop al tău, tu ești singurul care poate pune certificatul la loc. Pe un dispozitiv administrat, un profil de configurare sau un payload MDM îl poate reinstala la următorul check-in, de aceea 'revine' și de aceea ștergerea mai puternică nu ajută.

Află care magazin îl mai ține

Oamenii încep în aplicația Setări, care este singurul loc unde un certificat nu este stocat. Locațiile reale sunt magazinele de încredere ale sistemului, magazinul propriu al browserului și magazinul privat al aplicației.

Potrivește după numărul de serie sau după amprentă, niciodată după numele afișat. Numele afișate sunt stabilite de cel care a emis certificatul și sunt reutilizate: 'Example VPN' poate fi trei certificate cu trei chei diferite, unul încă folosit zilnic.

certutil -user -store My
certutil -store Root
openssl x509 -in vpn-client.pem -noout -subject -issuer -serial -fingerprint -sha256

Pe macOS, instrumentul security oferă aceleași fapte, iar find-identity arată ce certificate mai au o cheie privată atașată:

security find-certificate -a -c "Example VPN" -Z /Library/Keychains/System.keychain
security find-identity -v -p ssl-client

Șterge obiectul îngust, păstrează emitentul comun

Exportă înainte de a șterge. Fără o copie de siguranță, singura recuperare este reemiterea, ceea ce la o CA privată înseamnă întoarcerea la cel care administrează PKI-ul. PFX-ul exportat este și ceea ce predai dacă eliminarea se dovedește decizia greșită.

certutil -user -exportPFX -p backup My <serial> C:\temp\vpn-id.pfx
certutil -user -delstore My <serial>
Remove-Item Cert:\CurrentUser\My<thumbprint>

Flagul -user este cel pe care oamenii îl omit din greșeală. Fără el, certutil lucrează pe magazinul mașinii, ceea ce înseamnă un shell ridicat, un set diferit de certificate și o rază de impact care include acum toate celelalte conturi de pe mașină.

Pe macOS și Linux forma este aceeași: identifică, exportă, apoi elimină din cel mai îngust magazin care explică simptomul. Eliminarea fișierului din /usr/local/share/ca-certificates și rularea din nou a update-ca-certificates este suficientă; --fresh ajută doar când legăturile simbolice din /etc/ssl/certs sunt deja inconsistente. Sistemele din familia RHEL păstrează ancorele în /etc/pki/ca-trust/source/anchors, unde trust anchor --remove face aceeași treabă.

sudo security delete-certificate -Z <sha1> /Library/Keychains/System.keychain
sudo rm /usr/local/share/ca-certificates/example-vpn.crt
sudo update-ca-certificates
sudo trust anchor --remove /etc/pki/ca-trust/source/anchors/example-vpn.crt

Înainte de a șterge un certificat de CA, verifică ce altceva se înlănțuie cu el. Listarea subiecților din pachet este o verificare de două linii și răspunde dacă ancora face altă treabă:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep -i example

Ștergerea fișierului nu este revocarea identității

O ștergere locală înlătură o copie. Cheia privată poate sta în continuare într-un p12 atașat unui tichet vechi, într-un folder de copii de siguranță sau în al doilea laptop configurat în același timp. Dacă aceasta a fost o identitate de client, gateway-ul continuă să accepte orice copie a acelei chei până când identitatea este refuzată pe server.

Pentru o OpenVPN PKI, asta înseamnă revocarea certificatului și asigurarea că CRL-ul la care face referire crl-verify este actual; easyrsa revoke și apoi easyrsa gen-crl este versiunea scurtă. Pentru un gateway legat de un furnizor de identitate, dezactivează utilizatorul sau elimină dispozitivul acolo, pentru că certificatul este doar o acreditare în joc. Ștergerea copiei locale cât timp contul rămâne activ pare curățenie și nu este.

Munca de incident are altă ordine: păstrează mai întâi certificatul, numărul său de serie și înregistrarea revocării, apoi șterge și revocă. Acele înregistrări nu costă nimic și nu cer să lași o acreditare funcțională la loc.

Verifică printr-un handshake și o a doua aplicație

Verifică lanțul din exterior, nu din lista magazinului pe care tocmai ai editat-o. Magazinul îți arată editarea; handshake-ul arată rezultatul.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error < /dev/null
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt vpn-gateway.pem

Un cod de retur 0 înseamnă că ancorele rămase încă validează gateway-ul. O eroare de lanț după eliminarea ancorei este rezultatul așteptat și confirmă că ai lovit ancora în uz, nu un duplicat într-un magazin pe care clientul nu îl citește niciodată. Dacă conexiunea încă funcționează, caută o a doua copie, un magazin inclus în aplicație sau un certificat fixat, toate obișnuite la clienții care își aduc propria listă de încredere.

Apoi testează ceva nelegat: un site intern, un client de e-mail, o oglindă de pachete. Asta măsoară ieftin raza de impact, înainte de a se închide fereastra de schimbare.

• Rol identificat ca identitate, intermediar sau ancoră de încredere
• Număr de serie și amprentă înregistrate, iar copia exportată în locația aprobată
• Ștergere făcută în cel mai îngust domeniu care explică simptomul
• Autorizare pe server revocată când o persoană sau un dispozitiv a plecat
• Handshake explicat, și o aplicație nelegată retestată
• Payload MDM sau profil de administrare actualizat, altfel certificatul revine

Dacă certificatul a revenit după o repornire, treaba nu s-a terminat: ceva îl deține și îl reinstalează. Găsește acel proprietar înainte de a șterge din nou, pentru că a treia ștergere se va comporta exact ca primele două.