Revoked client still connects: the list never arrived
Revocation is an input to certificate verification, not a command that ends a session. Compare how a new connection and a running tunnel see the list.
Revocation never reaches into a running tunnel to delete a session. The list is an input to certificate verification, consulted during the control-channel exchange that begins a TLS session. That single fact explains both surprises: a revoked client reconnects because the list never reached the verifier, and an existing session survives because nobody re-verified anything.
A list is an input, not an action
During session setup the server validates the client certificate against its trust anchors, and the revocation directive adds a list lookup to that decision. The check happens on the server, so the client cannot see that its certificate was revoked and keeps offering the same one. A profile that still connects therefore proves only that some verifier accepted the chain, not that revocation failed.
The list is itself a signed object with an issue date and a next-update date. An unrelated list, one signed by a different authority or one whose next-update has passed is not a substitute for the current one, and whether a stale list is rejected or quietly accepted depends on the deployment.
New connection versus running session
Revocation is evaluated when a session is established or renegotiated, not against the data channel on every packet. A client that is already connected holds traffic keys, so it keeps passing packets after its certificate appears on the list. The default renegotiation interval is measured in hours, which is why an updated list can take effect for newcomers while a running tunnel stays up.
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
Immediate enforcement needs a deliberate action rather than the list alone. Restarting the service forces every client to reconnect, while terminating one session through the management interface leaves the others untouched. Choose one per incident and note which you used. The two options have different blast radius, and that is the real decision.
Deliver the file the verifier actually reads
The list has to be generated from the authority's record and then copied to every machine that verifies certificates. Generating it on the CA host and never installing it on the server is the most common failure, and it looks exactly like a broken revocation feature.
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pemTwo details decide whether the file is actually read. A relative path resolves against the configuration directory, so a copy left in an operator's home may never be found. And the daemon usually drops privileges after startup, so the runtime account needs search permission on every parent directory as well as read permission on the file. Check both with the runtime account rather than with root, or the test proves the wrong thing.
On systemd hosts a hardened unit can hide the path as well, with a read-only view or a protected system directory. From inside the service that is indistinguishable from a missing file, so check the unit's restrictions before you go looking for a permissions mistake. Read the unit file before blaming the file's mode.
Confirm on the server, not on the client
The server log names what happened: opening the list, loading it, or failing verification with the revoked serial. The client only reports a generic handshake failure, which is why client logs are a poor place to look for a revocation decision.
Verify with a fresh attempt from the revoked profile, then stop. A successful connection from that profile is the signal to inspect the file path and the runtime account, not to assume the list was wrong. Keep that successful attempt as the acceptance test, and do not count a reconnect you did not watch.
What does not revoke anything
Deleting the profile from a laptop, removing the certificate file from the client or telling the user to stop connecting changes nothing on the server. The certificate remains valid until the authority records the revocation and the verifier reads the resulting list.
That is also why the chain is worth writing down: record the revocation, generate and sign the list, distribute that exact file, and confirm the service account can read it. Each link is short, and any missing one leaves a revoked client connecting happily. A checklist with four lines beats an assumption with none.