0

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?

3 Answers 3

-1

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.

1
  • 3
    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, 2014 at 23:53
7

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.

2
  • 1
    Thanks for this. According to this test the key I'm looking at right now does not have a passphrase. So I have tried the same command, this time handing pass:x in, expecting it to fail and tell me that the passphrase x is incorrect. But actually it still exits with code 0 and echoes exact same output as it does with the empty passphrase... Turns out the absence of a "Proc-Type: 4,ENCRYPTED" line (serverfault.com/a/628980/253566) confirms, too, that the key lacks a passphrase so I guess when that's not present openssl ignores any passphrase provided.
    – thomanski
    Mar 16, 2016 at 16:49
  • Unfortunately, this is not working with OpenSSL 1.1.0g 2 Nov 2017, because of the openssl rsa requests a password via stdin.
    – andras.tim
    Nov 6, 2018 at 11:24
0

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.

You must log in to answer this question.

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