Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an OpenVPN server installed on a Debian machine.

Is there a way to find which of the keys have been created without being encrypted with a password, so as to replace them?

share|improve this question
add comment

3 Answers 3

up vote 1 down vote accepted

For keys without a password, the actual key usually starts at the second line and for keys with a password you can also find three additional lines.

You can do something like wc -l /etc/openvpn/easy-rsa/keys/*.key and the keys with less lines don't have a password.

Deleting the keys doesn't do anything in OpenVPN and users would still be able to connect with their certificate and key. You need to revoke the certificate of the user that you want to prevent from connecting.

share|improve this answer
2  
This will only be effective where all keys are the same size; if you have, say some 1024-bit keys and some 2048-bit keys then the latter will have a much larger file than the former. Additionally, only PEM format keys specify the encryption in this plain text fashion. –  Calrion Jan 28 at 23:53
add comment

You can use the openssl rsa command to determine if a key has been encrypted with a password or not:

if ! openssl rsa -passin pass:"" -in $keyfile > /dev/null 2>&1; then
  echo "$keyfile is encrypted."
fi

This attempts to decrypt the file with an empty passphrase, which works fine on unencrypted keys but will otherwise fail. See the "PASS PHRASE ARGUMENTS" section of the openssl(1) man page for more information about arguments to the -passin option.

share|improve this answer
add comment

OpenVPN uses SSL/TLS for its secutity, and so it uses SSL certificates and keys (that's why your question actually has nothing to do with OpenVPN). OpenVPN uses OpenSSL for dealing with (almost) all the security stuff, and its --key option (just key in configuration files) expects the key to be kept in the so-called PEM format (see this for a general overview; the format itself is defined in RFC 1421). Encrypted keys stored in PEM format are distinguished from unencrypted by having a set of special header fields defining the fact of encryption and the encryption algorythm used —here's an example.

So, stictly speaking, you should process each key file with a script which would try to perform some minimal amount of parsing: detect the header line (that ------- BEGIN ... thing) and then try to look at whether there are signs of encryption present. But this is possibly too involved for a one-off solution so I like the @larsks's answer best—it's brute-force but elegant and simple enough. Hence my answer is here just to put you into some context.


Note that it's strange why do you have clients' keys on the server: the server does not need neither the clients' keys nor their certificates—all it's interested in is access to these bits of information:

  • Its own certificate and the matching key.
  • The certificate of the CA which issued the server's certificate.
  • The so-called Certificate Revocation List (CRL) maintained by that CA.

The whole idea of OpenVPN trusting some but not all clients is rooted in the fact it only lets in those clients which present it valid certificates issued by the CA which the server trusts—most of the time it's the same CA which issued the server's certificate as well. There are ways to limit this, though:

  • Revoking a client's certificate.
  • Configuring OpenVPN in a way that it only lets in clients which have their special per-client configuration files (the so-called "ccd files", whose names match the subject names of the respective clients' certificates) present.
  • Making an openvpn client processing script check the information about the connecting client and fail connecting if this check fails.

Hence there's no need to keep client keys on the server: should a client lost their certificate and/or its key, your CA has to revoke it (updating the CRL) and issue another one. So keeping clients' public certificates around might be useful (for easier revocation) but even this is not required.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.