Sane crl.pem (revocation) configuration

[koma]

Hi

I'm currently auditing an oldish installation of OpenVPN for our company network. There are a few certificates around that need to be revoked (because those employees don't work for my company no more). But the revocation mechanism wasn't in place until I touched it.

We're running ubuntu server (I'm innocent) and basically the OpenVPN installation seems to be quite default: configuration in /etc/openvpn, easy-rsa (2.0) scripts in /etc/openvpn/easy-rsa, keys in /etc/openvpn/easy-rsa/keys. I checked some howtos and what seemed to be necessary was to add the following line to server.conf:

Code: Select all

crl-verify /etc/openvpn/easy-rsa/keys/crl.pem

Of course that didn't work right away, as the server drops its privileges after startup and the /etc/openvpn/easy-rsa/keys directory is readable and executable by root only (I checked, the scripts create it as 0700) but needs to be read on every connect. So even though crl.pem is set readable by others it's inaccessible for the server after launch. I fixed this by making the keys directory readable and executable by everyone, which enables ordinary users to get the filenames of the keys contained within, but still not read the keys. What made me wince was that the server would start up ok with no access to the crl.pem file, but would then exit on the first connection attempt.
Another problem was that an accessible but empty pem.crl also caused the server to exit on the first connection attempt.

So my questions basically are:
1. Why isn't the revocation mechanism enabled by default (that means at the same place in the docs where the easy-rsa mechanism is described with a default location for the crl.pem file) ? To me it seems to be a central concept that should just work ?
2. Why does the server exit on first connection attempt if there is some misconfiguration with the crl.pem file ? I think there should be a check for this just after dropping privileges - as it's really strange to have the server coming up just nicely (yaay, everything works - not) and then just exiting later because of a configuration issue.
3. Is it sensible to have the keys directory readable by everyone or does that pose a security risk of some kind ?


Basically my thoughts behind this are: I'm configuring the server now so that later other admins without deep knowledge of the OpenVPN configuration may revoke keys, update OpenVPN and do similar tasks. That's why I chose not the move the crl.pem file from the keys directory (as suggested in the openvpn docs) but rather set the directories permissions so the file is accessible. This way anyone can just use the revoke-full script and it should just work - no extra step of copying the file somewhere else is necessary, as forgetting this makes the revocation ineffective.

I want the configuration to be as robust as possible against quick-and-dirty usage. So is there a recommended way to do this or am I on my own ?

Thanks and regards,
koma

[janjust]

1. Why isn't the revocation mechanism enabled by default (that means at the same place in the docs where the easy-rsa mechanism is described with a default location for the crl.pem file) ? To me it seems to be a central concept that should just work ?

the easy-rsa scripts are just set of quick&dirty scripts to set up a PKI for using OpenVPN. It is by no means a full-fledged PKI solution. For most users a CRL is not required and would only add complexity (CRLs have expiration dates which can cause issue).

2. Why does the server exit on first connection attempt if there is some misconfiguration with the crl.pem file ? I think there should be a check for this just after dropping privileges - as it's really strange to have the server coming up just nicely (yaay, everything works - not) and then just exiting later because of a configuration issue.

This is a known bug in the openvpn code where any error found in a CRL file will cause the entire openvpn process to abort:
https://community.openvpn.net/openvpn/ticket/83

3. Is it sensible to have the keys directory readable by everyone or does that pose a security risk of some kind ?

Ideally, the keys directory should not be present on the OpenVPN server itself at all; you'd set up a PKI on a separate box and then copy over only the files needed for the server process: ca.crt, server.{crt,key}, dh*.pem and the CRL file. The CRL should be copied over regularly using some cronjob.

[koma]

Thanks for the fast reply, janjust !

Setting up a full-fledged PKI solution is definitely too "heavy" for our environment - we have about 15 OpenVPN keys to manage. Probably we rather are in the "not required" category - although I'm not sure how to disable old keys without a revoking mechanism (I should probably dive into the docs).

Thanks for the link to the bug ticket. Reading it just made me come up with another question: is it expected not to get a "your key is revoked" message on the client after revoking a key ? I can see a message about the key being revoked in the server log, but the client just tries to connect again and again.

So I'll just keep it as it is and put big fat warnings (tm) into our documentation.

Regards,
koma

[janjust]

Thanks for the link to the bug ticket. Reading it just made me come up with another question: is it expected not to get a "your key is revoked" message on the client after revoking a key ? I can see a message about the key being revoked in the server log, but the client just tries to connect again and again.

a similar topic was discussed recently on the openvpn-users mailing list:

http://comments.gmane.org/gmane.network ... user/33106

there are pros and cons to providing more info to a (malicious) client. Right now, nothing is reported and indeed, a client will keep reconnecting. But as you can read in the thread this might change in the future.