Suspend One OpenVPN Client Without Revoking Its Cert

When a laptop goes to a repair bench for a week, the usual instinct is to remove its certificate from the CA. That record is the issuer's ledger, not a temporary admission switch. OpenVPN already has a per-client mechanism for refusing a connection, and using it keeps the CA's history intact. The two controls answer different questions, and mixing them creates work when the device returns.

Two Records, Two Different Jobs

The CA database records what the issuer signed and what it later revoked. It is consulted by revocation workflows and by anything that reads the CRL or its own copy of the ledger. An admission rule lives on the server and applies to the connections that server accepts.

Deleting an issuance record does not reliably revoke a certificate, and it damages the history that later revocation or auditing depends on. The server-side control is narrower and reversible. Write the difference into the change note so the next person does not go looking for a revocation that never happened.

Put the Disable Directive in the Right File

For a community server that uses client-specific configuration, the documented disable directive refuses one selected client. It belongs in that client's file under the active client-config-dir, not in the main server configuration. Confirm the directory the running daemon actually uses, then confirm the identity that selects the file. A file named after the wrong common name looks correct and is never read.

disable

Mapping choices matter here. Options such as username-as-common-name change which identity the lookup uses, so a file named for the certificate subject may not be the one applied. Read the OpenVPN reference for the installed version rather than assuming a directive is valid in every context.

Separate New Admission From Live Sessions

Refusing the next handshake does not end a tunnel that is already up. If the device must be disconnected now, use the server's authorized session-management path for that specific session as well. Otherwise the client can keep working until it reconnects on its own, and closing the laptop lid or quitting the client is a client-side action that tells you nothing about the server.

Verify both outcomes: the live session stops when you intend it to, and a new handshake is denied. A closed client window proves nothing about the server's policy.

If the deployment has no supported way to end a live session, record that gap instead of improvising one. A blocked port on the client is not the same as a server-side policy.

Pause and Compromise Are Different Events

A lost or stolen key is a revocation event, and a local admission pause does not substitute for it. Other servers that trust the same CA will not share this server's client-specific rule. Follow the issuer's revocation and replacement process, and keep the CA database as the authoritative record. A temporary pause, by contrast, needs a documented reason and a restoration step.

When access is restored, remove the restriction through the component that owns it and confirm a new connection succeeds. Record the disable line's path as well, because a later configuration sync can quietly put it back. Keep the pause, its owner and the date in the deployment notes, so the next administrator does not find an unexplained disable line months later.