Lost the Client Certificate? Revoke by Serial, Not by Name

Your client's certificate file is gone, and the reflex is to revoke the name and issue a new one. That reflex leaves the original certificate valid, because revocation works on a serial number rather than on a label. The CA almost certainly still holds a copy of what it issued, and finding that copy is the whole task.

Losing a file is not losing the CA's record

An Easy-RSA PKI keeps the public certificates it issued, and current releases also archive copies by serial under the PKI's certs_by_serial directory. The private key is not needed to revoke anything. What matters is the exact certificate the CA signed, which the CA already has.

Work on a backed-up copy of the right PKI, with the administrator who owns it. Revocation is an auditable operation rather than a repair performed on a production database at midnight.

A copy of the client's inline public certificate works too, if the deployment kept one.

Read the issuer and serial before anything else

Inspect the recovered PEM and write down the issuer, the serial, the subject and the validity window. The serial is unique within one issuer's scope, not across every CA in your estate, so the issuer is part of the identity. If several certificates share a subject, those serials are what tell them apart.

Match the values against the CA's records and against the device or person you believe holds the certificate.

A common name can be reused, and it usually is. Do not decide which certificates to withdraw until the serials are written down.

Why revoking the new certificate does nothing

Issuing a replacement with the same common name creates a second certificate with a different serial. Revoking the replacement withdraws the new one and leaves the original valid until it expires. From the CA's point of view these are two independent objects, and a CRL lists serials rather than names. The CA index keeps one row per issued certificate for exactly that reason.

The same confusion produces the reverse mistake: deleting the client's file and assuming the CA forgot it. Deletion on the client is not a revocation event, and the certificate keeps working for anyone who has a copy.

Both mistakes come from treating the name as the identity.

Revoke the certificate the serial names

Identify the object before you touch the CA: openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates prints the four values in one pass, and the serial is what you match against the CA archive. Easy-RSA keeps that archive under pki/certs_by_serial, with one file named after each serial. The revoke command takes a common name rather than a serial, so copy the archived file to pki/issued/<common-name>.crt and let the name point at the object you identified. Run easyrsa revoke <common-name> from the PKI directory, then check that the matching row in index.txt has flipped to R. The serial is how you choose the object, not an argument the command accepts.

openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates
cp pki/certs_by_serial/A1B2C3D4.pem pki/issued/client-01.crt
./easyrsa revoke client-01
grep -n client-01 pki/index.txt
./easyrsa gen-crl

If index.txt does not show R, stop and read the error before generating a CRL, because a CRL built from a record that is still valid withdraws nothing. Only after the row flips do you run easyrsa gen-crl and move on to distributing the file.

Publish the CRL where it is actually enforced

Generate a new CRL through the PKI's supported workflow, then publish it to every verifier that enforces this issuer's revocations.

An updated file sitting on the CA changes nothing, because the VPN terminates the decision at its own verifier. Check the CRL's issuer, its validity period and the revoked serials, and confirm that the service reloads the file rather than caching the previous one. Ownership and path matter as much as content: a CRL the daemon cannot read is indistinguishable from no CRL at all. OpenVPN's crl-verify option names the file the daemon reads, so check that path and the file's ownership in the server config.

Verify with a real connection attempt, not with the file's timestamp.

Know when a CRL is the wrong tool

If the issuer's private key is no longer trusted, withdrawing known serials cannot stop an unauthorized holder from signing new certificates. That is an issuer-trust transition, meaning a new CA and a distribution plan, not another entry in the CRL. A former administrator having had access is not by itself evidence that the key was misused, so get the facts before rebuilding trust.

Editing the issuance database by hand to flip a status letter is not a substitute for a signed revocation, and it leaves the CRL inconsistent with the records.

Keep the serial, the CRL and the distribution step in one note, and the next audit becomes a reading exercise. The Easy-RSA project documents the supported commands for the release you have installed, which is the only interface worth following.