5

I'm setting up an OpenVPN server for my organization, and I'm reading up on the different ways that the client side keys work. I'm still a little unfamiliar with all of the concepts behind these client keys and account auth.

  1. What are the real benefits of using the ./build-key-pass vs the ./build-key to generate the client keys? Is this just similar to password protecting an SSH key? Not all of our employees who require an account are tech savvy, so is it worth introducing another set-up step?
  2. I see now that there is an option to not require typical username / password authentication when using client keys. My plan was to do a useradd on the server for each client. If I don't use the user-pass auth settings then how would I revoke access to a specific client?
  3. How can I securely deliver these client certificates to all of our employees who need an account? I believe that the client.key files are supposed to be private, and emailing the files seems like it would be insecure.
Improve this question

1 Answer 1

Reset to default
3

To respond to each of your points:

1 - You are correct in analogizing the password protection of OpenVPN keys to password protection of SSH keys.

2 - Without using any additional authentication method OpenVPN relies only on the verification of the client certificate by the server (and ideally verification of the server certificate by the client) for authentication of the client. This makes revoking an individual client's access a matter of either adding the client's certificate to a certificate revocation list (CRL) (supported by versions 1.5 and up of OpenVPN) or removing the key material from the client (or switching up the certificates on all your other clients). If you're not using an additional authentication method you need to have a CRL to allow for client access revocation.

Keep in mind that password protecting the keys doesn't help you at all re: additional authentication. That password just "unlocks" the key on the client device-- it doesn't alleviate the problem of additional authentication of the user on the client to the server computer (and the access revocation problem).

3 - You should generate the private / public key pairs on the clients themselves, as opposed to transmitting them over the wire. You can generate the certificate request on the client, send the public key (in a Certificate Signing Request) up to your CA for signing, and install the signed certificate on the client. This could all be scripted, and I'm sure somebody has already done it (and I'd hope that the commercially licensed OpenVPN product probably has some of that functionality built-in).

I find this My Certificate Wizard project that was written just for this purpose, but I'd go for scripting the entire thing on the client using the OpenSSL command-line tools in an attempt to make the entire process mostly invisible to the user.

Improve this answer
6
  • Great, thanks! I'm going to go with the user-password based authentication on top of the client certificate/key pair. As far as your response to question 3, is this just a suggestion or would security be fatally flawed if we transmitted password-protected keys over the wire?
    – andrewvnice
    Jan 29, 2014 at 1:00
  • If you have to send the keys over the wire they need to be password protected, at which point you've moved the key distribution problem from the private keys to the passwords protecting the private keys. I'd look for a way to generate the keys client-side, personally.
    – Evan Anderson
    Jan 29, 2014 at 1:03
  • I tend to slightly disagree with (2): denying access to a particular client has to be done by revoking its certificate--by adding its serial number to the CRL maintained by the CA, and the OpenVPN server should have access to that CRL--each time a client connects, the server checks the CRL. The upside of this approach is that it's easy to deal with cases like stolen devices.
    – kostix
    Jan 29, 2014 at 9:17
  • ...or, at my $dayjob, we twice had to deny the access to folks which have been fired and hence we just hadn't legal access to their devices with their private keys. For this reason we keep eash issued certificate (but not their matching private keys) near the CA for easy revocation just in case.
    – kostix
    Jan 29, 2014 at 9:21
  • @kostix - I will grant you that-- a properly-working PKI, completely with a CRL, would make revocation possible. More often than not, though, people knock-together a glue-and-tape PKI just for OpenVPN and don't spend the time putting together niceties like a CRL. Good point, though-- I'll drop on an edit.
    – Evan Anderson
    Jan 29, 2014 at 12:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .