So entfernen Sie ein veraltetes VPN-Zertifikat aus einem Trust Store

Ihr VPN-Client ist deinstalliert, das Profil ist aus den Einstellungen verschwunden, und der Tunnel kommt trotzdem mit den alten Anmeldedaten hoch. Oder Sie löschen ihn, starten neu und finden ihn am nächsten Morgen wieder. Keines von beidem ist ein defekter Löschknopf. Ein Profil ist Konfiguration; ein Zertifikat ist Schlüsselmaterial plus eine Vertrauensentscheidung, die in einem Speicher festgehalten wird, auf den das Profil nur verweist. Welches der beiden Sie in der Hand halten, entscheidet, was 'entfernen' bedeuten muss.

Ein Profil ist kein Zertifikat

Drei verschiedene Objekte werden in einem VPN-Setup 'das Zertifikat' genannt. Die Client-Identität ist ein Endzertifikat mit einem privaten Schlüssel, und das Gateway nutzt es, um zu entscheiden, wer Sie sind. Das eigene Endzertifikat des Servers und sein Zwischenzertifikat sind das, was Ihr Client beim Verbinden prüft. Das Vertrauensanker, meist ein Root- oder privates CA-Zertifikat, ist das, was die Kette überhaupt prüfbar macht. RFC 5280 nennt diese Vertrauensanker, Zwischenzertifikat und Endentität, und die Kette validiert nur, solange jedes Glied das darunter signiert.

Löschen Sie die Identität, und ein Gerät verliert den Zugriff. Löschen Sie den Anker, und jede Anwendung, die gegen diesen Speicher validiert, verliert die Fähigkeit, irgendetwas darunter Ausgestelltes zu prüfen, einschließlich Verbindungen, die nichts mit dem VPN zu tun haben. Diese Asymmetrie ist das ganze Risiko hier: Ein für ein Gateway installierter Root ist oft derselbe Root, der ein internes Portal, einen Mailserver oder einen Paketspiegel signiert. Merken Sie sich, welches der beiden Sie in der Hand halten.

Eigentum entscheidet, ob die Löschung gelöscht bleibt. Auf einem Laptop, den Sie besitzen, können nur Sie das Zertifikat wieder einsetzen. Auf einem verwalteten Gerät kann ein Konfigurationsprofil oder eine MDM-Payload es beim nächsten Check-in neu installieren, weshalb es 'zurückkommt' und weshalb härteres Löschen nicht hilft.

Finden Sie heraus, welcher Speicher es noch hält

Viele beginnen in der Einstellungen-App, dem einen Ort, an dem ein Zertifikat nicht gespeichert wird. Die tatsächlichen Orte sind die Trust Stores des Betriebssystems, der eigene Speicher des Browsers und der private Speicher der Anwendung.

Vergleichen Sie Seriennummer oder Fingerabdruck, niemals den Anzeigenamen. Anzeigenamen legt fest, wer das Zertifikat ausgestellt hat, und sie werden wiederverwendet: 'Example VPN' können drei Zertifikate mit drei verschiedenen Schlüsseln sein, eines davon noch täglich in Gebrauch.

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

Unter macOS liefert das security-Werkzeug dieselben Fakten, und find-identity zeigt, welche Zertifikate noch einen privaten Schlüssel angehängt haben:

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

Löschen Sie das enge Objekt, behalten Sie den gemeinsamen Aussteller

Exportieren Sie vor dem Löschen. Ohne Sicherung ist die einzige Wiederherstellung das Neuausstellen, was bei einer privaten CA bedeutet, zu dem zurückzugehen, der die PKI betreibt. Die exportierte PFX ist auch das, was Sie aushändigen, wenn sich das Entfernen als falsche Entscheidung erweist.

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

Das -user -Flag ist das, das Leute versehentlich weglassen. Ohne es arbeitet certutil stattdessen auf dem Maschinenspeicher, was eine erhöhte Shell, einen anderen Satz Zertifikate und einen Wirkungsradius bedeutet, der nun jedes andere Konto auf der Maschine einschließt.

Unter macOS und Linux ist die Form dieselbe: identifizieren, exportieren, dann aus dem engsten Speicher entfernen, der das Symptom erklärt. Die Datei unter /usr/local/share/ca-certificates zu entfernen und update-ca-certificates erneut auszuführen, genügt; --fresh hilft nur, wenn die Symlinks in /etc/ssl/certs schon inkonsistent sind. Systeme der RHEL-Familie halten Anker in /etc/pki/ca-trust/source/anchors, wo trust anchor --remove dieselbe Arbeit leistet.

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

Prüfen Sie vor dem Löschen eines CA-Zertifikats, was sonst noch dazu verkettet. Die Subjekte im Bundle aufzulisten ist eine Prüfung in zwei Zeilen und beantwortet, ob dieser Anker andere Arbeit leistet:

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

Die Datei zu löschen ist nicht, die Identität zu widerrufen

Ein lokales Löschen entfernt eine Kopie. Der private Schlüssel kann weiterhin in einer p12 liegen, die an einem alten Ticket, einem Sicherungsordner oder dem zweiten Laptop hängt, der gleichzeitig eingerichtet wurde. War dies eine Client-Identität, akzeptiert das Gateway weiterhin jede Kopie dieses Schlüssels, bis die Identität serverseitig verweigert wird.

Für eine OpenVPN -PKI bedeutet das, das Zertifikat zu widerrufen und sicherzustellen, dass die CRL, auf die crl-verify verweist, aktuell ist; easyrsa revoke dann easyrsa gen-crl ist die Kurzfassung. Bei einem Gateway, das an einen Identitätsanbieter gebunden ist, deaktivieren Sie den Benutzer oder entfernen Sie das Gerät dort, denn das Zertifikat ist nur eine Anmeldedaten im Spiel. Die lokale Kopie zu löschen, während das Konto aktiv bleibt, sieht nach Aufräumen aus und ist es nicht.

Vorfallarbeit hat eine andere Reihenfolge: Bewahren Sie zuerst das Zertifikat, seine Seriennummer und den Widerrufsdatensatz auf, dann löschen und widerrufen Sie. Diese Aufzeichnungen kosten nichts und erfordern nicht, eine funktionierende Anmeldedaten liegen zu lassen.

Prüfen Sie mit einem Handshake und einer zweiten App

Prüfen Sie die Kette von außen, nicht aus der Speicherauflistung, die Sie gerade bearbeitet haben. Der Speicher zeigt Ihre Änderung; der Handshake zeigt das Ergebnis.

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

Ein Rückgabecode von 0 bedeutet, dass die verbleibenden Anker das Gateway noch validieren. Ein Kettenfehler nach dem Entfernen des Ankers ist das erwartete Ergebnis und bestätigt, dass Sie den verwendeten Anker getroffen haben und nicht ein Duplikat in einem Speicher, den der Client nie liest. Funktioniert die Verbindung weiterhin, suchen Sie nach einer zweiten Kopie, einem in die App eingebetteten Speicher oder einem gepinnten Zertifikat, alles verbreitet bei Clients, die ihre eigene Vertrauensliste mitbringen.

Testen Sie dann etwas Unbeteiligtes: eine interne Seite, einen Mail-Client, einen Paketspiegel. Das misst den Wirkungsradius günstig, bevor das Änderungsfenster schließt.

• Rolle als Identität, Zwischenzertifikat oder Vertrauensanker identifiziert
• Seriennummer und Fingerabdruck erfasst und die Kopie an den freigegebenen Ort exportiert
• Löschung im engsten Umfang durchgeführt, der das Symptom erklärt
• Serverseitige Autorisierung widerrufen, als eine Person oder ein Gerät ging
• Handshake erklärt und eine unbeteiligte App erneut getestet
• MDM-Payload oder Verwaltungsprofil aktualisiert, sonst kommt das Zertifikat zurück

Ist das Zertifikat nach einem Neustart zurück, ist die Arbeit nicht erledigt: Etwas besitzt es und installiert es neu. Finden Sie diesen Eigentümer, bevor Sie erneut löschen, denn ein drittes Löschen wird sich genau wie die ersten beiden verhalten.