Are intermediate signing certs the only secure+practical way to manage OpenVPN client certs?

Question

My organization needs to issue (and revoke) OpenVPN client certificates for people working remotely.

Our system is based on a standard OpenSSL CA setup and the easy-rsa tools, and the whole directory lives in a git repo that IT team members clone locally on their laptops where they generate and sign VPN certs, and then update the remote repo.

The root CA private key's passphrase is stored separately in a local password management system that is itself protected with a password we don't store anywhere.

Our concern is that anyone who's ever been a member of the IT team and leaves, can easily keep a copy of the root CA private key and its passphrase and can generate and sign valid VPN certs at will even after theirs has been revoked. Currently, the only way to prevent this is to change the root CA key and re-issue VPN certs to all users (massive pain!)

What's the best practical solution that people use ?

1) Have better procedures and only generate/sign client VPN certs on a single host with a restricted access policy ? This will slow us down significantly in day to day operations and doesn't really prevent an admin to scp the private key somewhere else if they wanted to.

2) Protect the root CA key properly as above, but use intermediate certs for day-to-day VPN certs signing ? How does this work exactly ? When an IT team member leaves, I understand we can revoke the intermediate cert that's now "compromised" and issue a new one from the root CA, but what happens to the existing VPN certs that have been signed with the previous cert ? What I'm reading about intermediate certs seems to suggest that they remain valid, but I don't understand how.

Thanks!

Answer 1

There are really a few options. You could try to use a hardware security manager that would lock the key away and only allow signing. This would prevent any of the IT staff from accessing the key itself, but is a lot more complicated to set up.

You can also (and really should in either case) set up intermediate certificates so that the root isn't compromised by a working key compromise.

You could also implement a cryptographic time-stamping server that has a key that isn't available to IT. They could then sign as of a given cryptographically verified time and each IT staff member's certificate could be invalidated as of a certain time. The system could then trust certificates signed by that intermediate key up until a certain point, but not trust later certs or certs that are not time stamped. This would let you get around having to replace all keys they ever made when they leave.

Answer 2

One solution could be that any mentioned IT staff member capable of issuing certificates acts as his own intermediate CA. The chain, then, would look like:

root CA ---> VPN intermediate CA ---> Marks CA, Jasons CA, Dustins CA and so forth.

That way, if let's say Mark issues ten certificates and leaves the company, only his own intermediate CA needs to be revoked, thus reducing the impact to only ten users who then need new certificates.

Also, that solves the problem of anyone other than the highest ranking IT staff member (or even CTO) knowing and having access to the root CA password protected key file.

Answer 3

Well if you want to know what other people use, I've used OpenVPN w/ clients who authenticate via ldap to an active directory. When the person leaves, their account is disabled and they have access to nothing. In that same environment we also issue machine certs to every workstation, so that workstations that have joined our domain can access a different instance of OpenVPN w/out having the user to authenticate everytime, this is ideal for certain senarios (road-warriors, etc).

To try and aid with your problem, How big of a pain is it to reissue certs? I don't know if you have something like puppet or sccm where you can deploy scripts or certs to machines, but that may be a thought.

Furthermore, a good way to run a CA is to have it be a server (either physical or virtual) with restricted access (some type of user authentication), so that not just anyone can access it and start generating certs.

Answer 4

Well I will try to answer your questions:

1. I think that this is the solution. I don't think that this will slow down the generation of a new certificate very much. For the problem of stealing the key: This problem is immanent to all such solutions.

2. This will only shift your problems. It does not matter for this if you have a root CA or an intermediate CA. The CA certificate must be revoked and a new must be issued. So the problems remain the same no matter if you have intermediate or root certificates.