Detect unencrypted SSL keys

Question

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?

Answer 1

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

if ! openssl pkey -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.

Answer 2

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.

Answer 3

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.