Revoked the wrong VPN certificate? Recovery options and limits

Someone revoked a certificate in the CA console and now a user cannot connect. The first instinct is to find the undo, and for most PKIs there is not one: revocation is a stated fact about a serial, and the supported path back is a new certificate, not a reversed record. Work through the checks below in order, because which repair you are allowed to use depends on the reason code and on whether the key was ever exposed.

Identify the certificate, not the person

Common names repeat. A user who re-enrolled last quarter may hold two certificates with the same CN and different serials, and revoking one leaves the other working. Establish the exact object first:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Write down the serial, the issuer, the revocation date and the reason recorded in the CRL. Then confirm which devices present that serial, because a revoked certificate may still be installed on a laptop, a phone and a spare router, and a replacement that reaches only one of them produces a second incident.

A quick behavioural check confirms the state without changing anything:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

If that reports the certificate as revoked, the CRL and the client agree; if it verifies cleanly, the client you are holding is not the revoked one, and the search continues.

Check whether the CA used hold or permanent revocation

RFC 5280 defines certificateHold as a temporary state, and removeFromCRL as the signal that releases it. That lifecycle is real, but it is not a general undo button. Reading the reason code tells you whether the issuer ever intended to support release.

The trap is assuming that a temporary intention implies a temporary record. If the CA entry carries keyCompromise or cessationOfOperation, the certificate is permanently revoked no matter what the person who clicked the button meant to do. Conversely, an entry marked certificateHold on a CA that does not implement hold release is permanent in practice, because nothing will ever publish the release.

OpenSSL-based CAs illustrate the limit. The ca command accepts -crl_reason values including certificateHold and removeFromCRL, but it does not generate delta CRLs — the OpenSSL CA documentation states that limitation for its CRL output. A full CRL that simply omits the serial is a different publication model from a delta that says "this entry is released", so pasting removeFromCRL into an OpenSSL-based VPN CA does not produce the standards-defined release.

If the key may have been exposed, replace it

A revoked certificate is a statement that this key may no longer be trusted. If the revocation was correct in substance — laptop lost, key copied to a shared drive, private key pasted into a ticket — restoring the same certificate reverses a security decision that was working as intended.

Issue a new key pair through the enrolment process, distribute the new profile, and leave the old serial revoked for its full lifetime. Update anything that pins identity by serial or fingerprint, including admission lists, device inventories and monitoring that expects a specific certificate.

The convenience argument for restoring the old one is real but should be answered explicitly rather than quietly. "The user needs access today" is a reason to speed up issuance, not a reason to un-revoke a key you cannot account for.

If it was an administrative mistake, replace under control

When the revocation was simply wrong and the key was never exposed, the repair is still a controlled replacement rather than an edit. Use the issuer's supported process, keep the serial and issuance history intact, and avoid the two tempting shortcuts: flipping the status character in index.txt from R back to V, and deleting the issuance row so a new certificate can reuse the serial.

On an OpenSSL CA the database is tab-separated and easy to misread, which is what makes hand-editing attractive:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Read it, do not write it. Editing the file changes the next CRL without any audit trail, and any second CA instance or backup that still holds the original row will disagree with it later.

After issuing the replacement, publish a fresh CRL through the normal mechanism and let clients pick it up. Removing a CRL, shortening its lifetime to nothing or disabling revocation checking in the client profile fixes one user by weakening every other revocation the CA has ever published.

Confirm a fresh admission and keep the record

Test with a new connection, not the session that was already open. A live tunnel may not re-run the admission checks that a fresh handshake performs, and CRL caches mean a client can keep connecting until it refreshes. Disconnect, reconnect, and confirm in the server log which serial was admitted.

Record what happened while it is still fresh: which serial was revoked, by whom, with which reason, which replacement was issued, and when the CRL was republished. That record is what makes the next revocation review possible, and it is also the evidence that the mistake was handled rather than hidden.

For short suspensions in future, use an admission-pause mechanism if the deployment has one — an account disabled at the identity layer, a group membership removed, a client profile withheld. That keeps a temporary policy decision separate from the question of whether an issued certificate is still trustworthy, which is exactly the distinction that got lost the first time.