How to Remove an Obsolete VPN Certificate From a Trust Store

Your VPN client is uninstalled, the profile is gone from Settings, and the tunnel still comes up with the old credentials. Or you delete it, reboot, and find it back the next morning. Neither is a broken delete button. A profile is configuration; a certificate is key material plus a trust decision recorded in a store the profile only points at. Which one you are holding decides what "remove" has to mean.

A profile is not a certificate

Three different objects get called "the certificate" in a VPN setup. The client identity is a leaf certificate with a private key, and the gateway uses it to decide who you are. The server's own leaf and its intermediate are what your client checks when it connects. The trust anchor, usually a root or a private CA certificate, is what makes the chain verifiable at all. RFC 5280 names these the trust anchor, the intermediate, and the end entity, and the chain validates only while each link signs the one below it.

Delete the identity and one device loses access. Delete the anchor and every application validating against that store loses the ability to check anything issued under it, including connections with nothing to do with the VPN. That asymmetry is the whole risk here: a root installed for one gateway is often the same root that signs an internal portal, a mail server, or a package mirror. Remember which of the two you are holding.

Ownership decides whether the deletion stays deleted. On a laptop you own, you are the only one who can put the certificate back. On a managed device, a configuration profile or an MDM payload can reinstall it at the next check-in, which is why it "comes back" and why deleting harder does not help.

Find which store still holds it

People start in the Settings app, which is the one place a certificate is not stored. The real locations are the OS trust stores, the browser's own store, and the application's private store.

Match on the serial or the fingerprint, never on the display name. Display names are set by whoever issued the certificate and get reused: "Example VPN" can be three certificates with three different keys, one still in daily use.

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

On macOS the security tool gives the same facts, and find-identity shows which certificates still have a private key attached:

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

Delete the narrow object, keep the shared issuer

Export before you delete. Without a backup the only recovery is reissuing, which on a private CA means going back to whoever runs the PKI. The exported PFX is also what you hand over if the removal turns out to be the wrong call.

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

The -user flag is the one people drop by accident. Without it, certutil works on the machine store instead, which means an elevated shell, a different set of certificates, and a blast radius that now includes every other account on the box.

On macOS and Linux the shape is the same: identify, export, then remove from the narrowest store that explains the symptom. Removing the file under /usr/local/share/ca-certificates and rerunning update-ca-certificates is enough; --fresh only helps when the symlinks in /etc/ssl/certs are already inconsistent. RHEL-family systems keep anchors in /etc/pki/ca-trust/source/anchors, where trust anchor --remove does the same job.

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

Before deleting a CA certificate, check what else chains to it. Listing the subjects inside the bundle is a two-line check and it answers whether that anchor is doing other work:

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

Deleting the file is not revoking the identity

A local delete removes one copy. The private key can still sit in a p12 attached to an old ticket, a backup folder, or the second laptop set up at the same time. If this was a client identity, the gateway keeps accepting any copy of that key until the identity is refused server-side.

For an OpenVPN PKI, that means revoking the certificate and making sure the CRL referenced by crl-verify is current; easyrsa revoke then easyrsa gen-crl is the short version. For a gateway tied to an identity provider, disable the user or remove the device there, because the certificate is only one credential in play. Deleting the local copy while the account stays active looks like cleanup and is not.

Incident work has a different order: preserve the certificate, its serial and the revocation record first, then delete and revoke. Those records cost nothing and do not require leaving a working credential in place.

Verify with a handshake and a second app

Check the chain from the outside, not from the store listing you just edited. The store shows your edit; the handshake shows the result.

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

A return code of 0 means the remaining anchors still validate the gateway. A chain error after removing the anchor is the expected outcome, and it confirms you hit the anchor in use rather than a duplicate in a store the client never reads. If the connection still works, look for a second copy, an app-bundled store, or a pinned certificate, all common in clients that ship their own trust list.

Then test something unrelated: an internal site, a mail client, a package mirror. That measures blast radius, cheaply, before the change window closes.

• Role identified as identity, intermediate, or trust anchor
• Serial and fingerprint recorded, and the copy exported to the approved location
• Deletion done in the narrowest scope that explains the symptom
• Server-side authorization revoked when a person or device left
• Handshake explained, and one unrelated app re-tested
• MDM payload or management profile updated, or the certificate returns

If the certificate is back after a reboot, the job is not finished: something owns it and reinstalls it. Find that owner before deleting again, because a third deletion will behave exactly like the first two.