Wéi en verouderde VPN-Zertifikat aus engem Trust Store läscht

Äre VPN-Client ass deinstalléiert, de Profil ass aus den Astellungen verschwonnen, an den Tunnel kënnt nach ëmmer mat den ale Umeldungsdaten erop. Oder Dir läscht en, startet nei, an fannt en den nächsten Moien erëm. Keng vun deenen zwee ass e defekten Läschknäppchen. E Profil ass Konfiguratioun; en Zertifikat ass Schlësselmaterial plus eng Vertrauensentscheedung, déi an engem Späicher festgehale gëtt, op deen de Profil just weist. Ween vun deenen zwee Dir hält, entscheet, wat 'läschen' bedeite muss.

E Profil ass keen Zertifikat

Dräi verschidden Objete ginn an enger VPN-Astellung 'den Zertifikat' genannt. D'Client-Identitéit ass en Endzertifikat mat engem private Schlëssel, an de Gateway benotzt en, fir ze entscheeden, wien Dir sidd. Den eegenen Endzertifikat vum Server an säin Zwëschenzertifikat sinn dat, wat Äre Client beim Verbannen kontrolléiert. Den Trust Anchor, meeschtens en Root- oder private CA-Zertifikat, ass dat, wat d'Kette iwwerhaapt verifizéierbar mécht. RFC 5280 nennt dës Trust Anchor, Zwëschenzertifikat an Endentitéit, an d'Kette validéiert nëmmen esou laang wéi all Glidd dat drënner ënnerschreift.

Läscht d'Identitéit an een Apparat verléiert den Zougang. Läscht den Anchor an all Applikatioun, déi géint dee Späicher validéiert, verléiert d'Fäegkeet, alles z'ënnersichen, wat dorënner ausgestallt gouf, inklusiv Verbindungen, déi näischt mam VPN ze dinn hunn. Déi Asymmetrie ass de ganzen Risiko hei: e Root, deen fir ee Gateway installéiert gouf, ass dacks dee selwechte Root, deen en internen Portal, e Mailserver oder e Paketspigel ënnerschreift. Denkt drun, ween vun deenen zwee Dir hält.

Propriétéit entscheet, ob d'Läschen geläscht bleift. Op engem Laptop, deen Dir besëtzt, sidd Dir deen eenzegen, deen den Zertifikat zrécksetze kann. Op engem verwalteten Apparat kann e Konfiguratiounsprofil oder eng MDM-Payload en beim nächsten Check-in erëm installéieren, dofir 'kënnt en zréck' an dofir hëlleft méi haart läschen net.

Fannt eraus, wéi ee Späicher en nach hält

D'Leit fänken an der Astellungen-App un, dat ass déi eenzeg Plaz, wou en Zertifikat net gespäichert gëtt. Déi richteg Plazen sinn d'Trust Stores vum Betribssystem, dee vum Browser selwer an dee private vun der Applikatioun.

Vergläicht d'Seriennummer oder den Androck, ni den ugewise Numm. Ugewise Nimm ginn vun deem gesat, deen den Zertifikat ausgestallt huet, a ginn erëm benotzt: 'Example VPN' kënnen dräi Zertifikate mat dräi verschiddene Schlësselen sinn, een dovun nach am dagdeegleche Gebrauch.

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

Op macOS gëtt d'security-Werkzeug déi selwecht Fakte, an find-identity weist, wéi eng Zertifikate nach e private Schlëssel drun hunn:

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

Läscht den engen Objet, behält den gedeelten Aussteller

Exportéiert, ier Dir läscht. Ouni Backup ass déi eenzeg Erhuelung eng Neiausstellung, wat op enger privater CA bedeit, zréckzegoen bei deen, deen d'PKI bedreift. Den exportéierte PFX ass och dat, wat Dir iwwergitt, wann d'Entferne sech als falsch Entscheedung erweist.

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

Den -user -Flag ass deen, deen d'Leit aus Versehen ewechloossen. Ouni en schafft certutil um Maschinnespäicher, wat eng erhéicht Shell, en anere Set Zertifikate an en Impaktradius bedeit, deen elo all anert Kont op der Maschinn enthält.

Op macOS a Linux ass d'Form déiselwecht: identifizéieren, exportéieren, dann aus dem engste Späicher eraushuelen, deen de Symptom erkläert. D'Datei ënner /usr/local/share/ca-certificates eraushuelen an update-ca-certificates nei ausféieren ass genuch; --fresh hëlleft nëmmen, wann d'Symlinks an /etc/ssl/certs schonn inkonsistent sinn. Systemer vun der RHEL-Famill halen Ankeren an /etc/pki/ca-trust/source/anchors, wou trust anchor --remove déiselwecht Aarbecht mécht.

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

Ier Dir en CA-Zertifikat läscht, kuckt, wat nach alles dorun kettet. D'Subjekter am Bundle opzielen ass eng Kontroll an zwou Zeilen an et äntwert, ob deen Anchor aner Aarbecht mécht:

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

D'Datei läschen ass net d'Identitéit widerrufen

Eng lokal Läschung hëlt eng Kopie ewech. De private Schlëssel kann nach an enger p12 sinn, déi un engem ale Ticket, engem Backup-Ordner oder dem zweeten Laptop hänkt, deen zur selwechter Zäit ageriicht gouf. Wann dëst eng Client-Identitéit war, akzeptéiert de Gateway weider all Kopie vun deem Schlëssel, bis d'Identitéit op der Serversäit verworf gëtt.

Fir eng OpenVPN PKI bedeit dat, den Zertifikat ze widerrufen an ze sécherzegestellen, datt d'CRL, op déi crl-verify verweist, aktuell ass; easyrsa revoke dann easyrsa gen-crl ass déi kuerz Versioun. Fir e Gateway, dee mat engem Identitéitsprovider verbonnen ass, deaktivéiert de Benotzer oder hëlt den Apparat do erof, well den Zertifikat just eng Umeldung am Spill ass. D'lokal Kopie läsche, wärend de Kont aktiv bleift, gesäit aus wéi Botzen an ass et net.

Inzidentaarbecht huet eng aner Reihenfolg: bewahrt fir d'éischt den Zertifikat, seng Seriennummer an den Widerruffsnotiz, läscht an widerruft dann. Déi Notizen kaschten näischt a verlaangen net, eng funktionéierend Umeldung stoen ze loossen.

Verifizéiert mat engem Handshake an enger zweeter App

Kontrolléiert d'Kette vun dobaussen, net aus der Späicherlëscht, déi Dir just editéiert hutt. De Späicher weist Är Ännerung; den Handshake weist d'Resultat.

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

En Zeréckcode vun 0 bedeit, datt déi reschtlech Ankeren de Gateway nach validéieren. E Kettefehler nodeems den Anchor erausgeholl gouf ass dat erwaart Resultat, an et bestätegt, datt Dir den Anker am Gebrauch getraff hutt an net en Duebel an engem Späicher, deen de Client ni liest. Wann d'Verbindung nach funktionéiert, sicht eng zweet Kopie, e Späicher, deen an d'App agebaut ass, oder en agepinnten Zertifikat, alles heefeg a Clienten, déi hir eege Vertrauenslëscht matbréngen.

Testt dann eppes onverbonnen: eng intern Säit, e Mailclient, e Paketspigel. Dat misst den Impaktradius bëlleg, ier d'Ännerungsfenster zougeet.

• Rolle identifizéiert als Identitéit, Zwëschenzertifikat oder Trust Anchor
• Seriennummer an Androck festgehalen, an d'Kopie op déi approuvéiert Plaz exportéiert
• Läschung am engsten Ëmfang gemaach, deen de Symptom erkläert
• Serversäit-Autorisatioun widerrufen, wéi eng Persoun oder en Apparat fortgaang ass
• Handshake erkläert, an eng onverbonnen App nach eng Kéier getest
• MDM-Payload oder Verwaltungsprofil aktualiséiert, soss kënnt den Zertifikat zréck

Wann den Zertifikat no engem Neistart zréck ass, ass d'Aarbecht net fäerdeg: eppes besetzt en an installéiert en erëm. Fannt deen Propriétaire, ier Dir nach eng Kéier läscht, well eng drëtt Läschung sech genee wéi déi éischt zwee verhält.