Here's what I did:

1. Create a test cert so that I could validate my process.
2. Create a new CA to sign the new certificates.
3. Create a new server ca. Note that this step is not necessary; the clients could still validate the old server cert against the old ca. However, I wanted to start fresh.
4. Create new client certs for all clients.
5. Add the new CA to the ca.crt file, in addition to the old CA. This allows both new and old clients to connect, which is useful for testing.
6. Distribute the new certs and CA to the clients
7. Restart OpenVPN on clients and server

Note: OpenVPN appears to use a cert revocation list. That's too bad. It would be preferable (from a security point of view) to have it use an access list, where certs are denied by default. That way, if there were unknown certs out there (ex: if this ex-employee made his own before he was terminated) then we wouldn't run the risk of having a backdoor into the system.

1. Find out what certs are being used

Check the logs.

1. Find out who is using them (so I'm not blocking legitimate users)

Reconcile the logs with the known IPs of the user?

1. Block the ones that I don't want to be given access

Ya got me there. It's been so long since I've used OpenVPN I can't remember if you can disable/remove individual certificates.

(P. S. Thank you yet-another-mark-up-language for renumbering my 1-2-3 into 1-1-1.)

Do you know what IPs the former employee was using? If not, I think you're going to have a tough time reconciling the logs, and you'd be better off starting to reissue certs to people who are using them, and revoking all the other ones.

And this time, you can keep a log. :-)

Certificate Revokation appears to be the major method OpenVPN supports. In order to do this securely, you must be certain that you know about every signed certificate ever created. Perhaps some environments can rely on this, but we can't.

Therefor, the only sure way to allow only certain people onto the network is to reenerate the certificates (both server and client), reissue them, and then reconfigure all the clients. That's definitely an ugly process.

I think the best bet is to enable an alternative authentication method, use that to allow/restrict access, and not worry so much about revoking certificates.

Whatever you decide to do, you should make sure it's not something you are going to have to do again the next time someone leaves.

It will probably also involve disturbing the other users because nobody thought about this up front.

The simplest might be to create a second layer of security, perhaps a password protected program that everyone has to run within a minute of logging in. If they don't run it, the system will kick them and tag their cert as questionable for you to review. If they do run it, it tags their cert as authorized and they shouldn't have to do it ever again.

Straight from the source:

OpenVPN HowTo: Revoking Certificates

This might be a good time for an audit. Might as well solve the underlying problem before it turns into a disaster.

Depending on your circumstances you might:

• Ask your users to connect to the VPN by a certain deadline so you can capture their certificate information and disable any who haven't connected, or

• If nothing mission-critical is at stake, disable all certificates and ask your users to contact you to re-enable their access.

Either way, you'll end up knowing exactly where each active certificate is.