What Happens When You Replace a VPN Certificate Authority

Replacing a VPN certificate authority is not a file swap. The moment the new CA signs its first certificate, every validator that still trusts only the old one has a decision to make, and hosts that never receive the new anchor keep rejecting good peers. I have seen it go wrong both ways: the gateway learned the new CA while the clients did not, so new connections failed, while tunnels already up stayed up and made the outage look like a routing problem. Here is what changes, in the order failures appear.

One replacement, two separate changes

A certificate authority is a name, a public key, and the private key that signs. Validators never trust "the CA" in the abstract. They trust one specific certificate that already sits in a trust store, and they accept an issuer only if a chain of signatures reaches that stored copy. Replacing the CA therefore changes two things that fail independently: which anchors are accepted, and which peer identities were issued under them.

Most VPN deployments validate in both directions. The client authenticates the gateway certificate, and the gateway authenticates the client certificate. A rollover that only refreshes the client bundle leaves the server rejecting every client that still presents an old-CA identity, and the reverse is just as common. Inventory the enforcement points first: client trust stores, the gateway's ca file, any TLS-terminating proxy in front of it, and the probe that checks the endpoint from outside.

What a validator checks, in order

Path validation climbs from the peer certificate through any intermediates until it reaches a trusted anchor. At each step it verifies the signature, checks that every certificate is inside its validity window, and confirms that basic constraints and key usage allow the issuer to sign. Only then does the application look at the leaf: the subject alternative names must cover the name that was dialled, and the extended key usage must permit server or client authentication.

You can reproduce that walk offline. Point -CAfile at the exact bundle you will deploy rather than at the system store, otherwise you are testing the host, not the change:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

That command only works against a plain TLS listener such as the gateway's HTTPS admin page; OpenVPN's control channel precedes TLS, so s_client cannot inspect the tunnel handshake.

The path-building rules behind those errors are in RFC 5280 section 6. They explain the failures that otherwise look arbitrary: an expired intermediate nobody remembered, a certificate whose key usage forbids signing, or a name constraint that excludes the host you are testing.

Why the old tunnel keeps working

TLS and OpenVPN both keep an established session alive after the handshake finishes. Nothing re-validates the peer certificate per packet, so a client that connected before the change keeps passing traffic until it renegotiates, reconnects, or the tunnel drops. That gap is why a CA replacement can look fine for an hour and then fail at the worst moment: a laptop wakes from sleep, a NAT mapping times out, a gateway restarts.

Session resumption stretches the illusion further. A TLS session ticket lets a client return without re-sending certificates, and resumption skips path validation because the first handshake already did it. So the honest test is a full handshake on a fresh process. Restart the client rather than reconnecting the tunnel, and on a test profile consider disabling tickets so the resume path cannot hide a broken chain.

Keep the static-key layer separate from this. tls-auth adds an HMAC to the control channel, tls-crypt encrypts and authenticates it, and neither carries certificate material, so rotating either is a separate change with its own failure mode. Deployments that conflate the two end up with a client whose static key is fine, whose certificate is stale, and whose error message mentions neither.

The trap of reusing the subject name

It is tempting to reuse the predecessor's distinguished name so nothing downstream has to change. That keeps the issuer line stable in the UI and destroys the one signal you need. Two certificates with identical subjects and different keys cannot be told apart by name, so a bundle holding both anchors hands the validator two candidates and no rule for choosing.

Path building may then pick the wrong one, report "unable to get local issuer certificate" while the correct anchor is present, or succeed on one host and fail on another holding the same bundle, because the candidate order differed. If the name must be reused, keep both anchors in separate files during the transition and load them explicitly, then merge them only once every peer presents the new issuer. Otherwise give the replacement a distinct common name, a generation or date suffix is enough, so logs and error strings say which authority a failing peer was issued under.

A rollover that does not take the network down

For a planned replacement, accept both anchors for a bounded window instead of switching in a single step. Issue the new CA and its intermediates, put the new anchor into every validator's bundle beside the old one, and only then begin issuing peer certificates from it. Peers with old identities validate against the old anchor; new ones work against the new anchor.

Done in that order, each step is reversible. The failure you are avoiding is the simultaneous switch, where a client that missed the bundle update meets a gateway that already retired the old anchor, the handshake dies, and neither log says which side is stale.

Retire in the opposite direction. Re-issue every identity that must survive, confirm each presents the new chain, then remove the old anchor from the bundles. Take the old CA private key out of service, since an issuer that can still sign means the rollover is unfinished. Keep the certificate and issuance records for audit. A lost issuer is restored to the same trust; an exposure requires new identities and no return to the old anchor.

Verify the outcome, not the file list

A trust file in the expected directory proves little. The application may read a different path, a different format, or a copy inside a package an upgrade replaces. Check behaviour at both ends, not that a file exists.

Confirm that a fresh connection with a new identity succeeds, then confirm that an identity issued by the retired CA is refused. That second test is the one people skip, and the only one that shows the old authority no longer grants access. Where the deployment relies on CRLs or OCSP, check that the distribution points in the new certificates resolve and the responder is reachable from the peers that query it.

Finish with a client that has never connected: wipe its profile state, connect, and read the negotiated chain. A peer resuming a cached session will cheerfully report that the migration worked when it validated nothing at all.