Replacing a Leaked VPN Key: What the Server Must Do

A laptop carrying a client key was lost, and the first action is usually to delete the local copy. That changes nothing on the server, which still holds an authorization that will accept that key until someone removes it. Replacement is two operations, and only the second one concerns the old credential.

The local copy is not the authority

A VPN credential is accepted because the server-side configuration says so. For certificates that means the certificate chains to a trusted issuer and does not appear on a revocation list the gateway consults. For WireGuard it means the peer's public key appears in the interface configuration. Deleting a file on a client removes one copy of a secret and leaves the acceptance rule untouched.

That is why a stolen key keeps working after the obvious cleanup, and why the incident feels unresolved even when the new configuration is installed.

Start from the server's rule, then work outward to the client.

Certificates: the server holds the decision

Issue the replacement through the issuer's own process so the new identity is recorded, then withdraw the old one with a signed revocation. The gateway has to be configured to consult that revocation source, and it has to reload it, or the file sits on disk while the tunnel keeps accepting the old serial. Active sessions can also survive until renegotiation, so plan a reconnect.

Confirm the replacement works for the intended application, then confirm through an approved process that the retired certificate no longer establishes access.

Those are two different tests and both are required. RFC 5280 defines the certificate and revocation semantics the gateway is relying on.

WireGuard: the peer key is the identity

WireGuard has no certificate layer: the peer's public key is the identity, and the server's allowed-ips entry is the authorization. Removing the old peer from the interface configuration is the revocation, and it applies to new handshakes immediately.

Existing sessions end when the next handshake fails, which is usually within a couple of minutes rather than instantly.

Distribute the new configuration through a channel you would trust with a password, because the private key is the credential. Keep one key per device, so a single lost device does not force every device to change.

What else was in that bundle

A client bundle often carries more than the private key: a static TLS key, a username and password, a pre-shared secret or a provisioning token. Scope the incident to what was actually exposed and rotate those items too. Rotating the certificate while leaving a shared static key in place closes one door and leaves another open.

If the bundle was shared across devices, every device carrying it inherits the exposure.

Write down what was rotated, because the next audit will ask.

Prove denial, then record the replacement

The replacement is complete when two facts hold: the new identity works for the intended service, and the old one is refused. Verify the second with the retired credential from a test environment, or with a controlled attempt the organization approves, and read the gateway logs to confirm the refusal came from policy rather than from a typo. Then record the old identifier, the new one and the time of the change, because those three values are what an auditor needs to reconstruct it. Nothing else in the ticket will explain the gap.

Keep private keys out of tickets and chat, and remove obsolete exports from storage and backups according to policy.

A replacement without a denial test is an assumption rather than a fix.