3

I have an existing PKI into which I am trying to integrate an OpenVPN server. I have included CRL Distribution Points into each CA certificate in my chain and I publish the CRLs at a location that is reachable from my OpenVPN server.

The problem is that the OpenVPN server seems to completely ignore the CRL Distribution Points extension in favour of its own --crl-verify option. If I revoke a certificate for a user and publish a new CRL, OpenVPN will happily continue to let that client connect. I don't understand why OpenVPN doesn't read these extensions given that they were added exactly for this purpose.

I can only think of 2 alternative ways to check my CRLs:

1) I can have a cronjob that copies the CRLs to the OpenVPN server and use the --crl-verify option. But since I have a chain of CAs, how do I get all the CRLs into one file? If I use the folder mode of --crl-verify, is it a problem that each CA in the chain has its own serial number scheme?

2) I have tried to avoid calling any external scripts in favour of using only builtin stuff under the assumption that the more I do manually, the more likely I am to introduce a security weakness. Am I wrong? Is writing my own script to check my CRLs the correct option?

Is there any way that I can get OpenVPN to check the CRL Distribution Points included in my certificate chain, preferably using a mechanism built into OpenVPN itself?

EDIT: It would also be nice to know if there are any ways to do this on the client side as well (ie, for clients to check the validity of the OpenVPN server's certificate). It would be so much simpler if --crl-verify took a URL.

succulent_headcrab
  • 387
  • 2
  • 6
  • 12
  • If you have a chain of CAs, you only need to download the CRL from the most subordinate one in order to revoke your client certificates. – garethTheRed Jun 05 '17 at 19:38
  • @garethTheRed Assuming that the client certs are all signed by the same cert, this might be a viable simplification of the problem. – Håkan Lindqvist Jun 05 '17 at 19:47

1 Answers1

3

I believe that you are correct that OpenVPN does not have this functionality.
As for why, I have no answer other than the general feeling that OpenVPN is more commonly set up with their own fairly simplistic easy-rsa for a dedicated PKI.

It does not appear that --crl-verify ... would play nice with CRLs for multiple CAs.

However, if you use --capath dir rather than --ca file to configure your CAs, the capath option expects both the CA cert and CRL in that directory. I believe this would be the workable option if you go with regularly exporting the CRLs to the OpenVPN server.

The other option, and I do agree that you should be careful with how it is implemented, would be to hook in a script.
You could use the --tls-verify cmd hook combined with --tls-export-cert directory and the peer_cert environment variable.
This would allow your custom script, with the peer's certificate at hand, to have the final say if the TLS handshake should succeed or not.

(See the above mentioned configuration options in the manual for details.)

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • The `--capath` option might do the trick combined with a cronjob. Too bad there's no way to do something similar on the clients. Thanks. – succulent_headcrab Jun 05 '17 at 20:12
  • 1
    I've implemented and tested your suggestion to use `--capath` and it works with 1 caveat: The server doesn't re-read the CRLs in capath until it is restarted. You have to keep incrementing the suffix `(CRL.r)` as you fetch new CRLs while the server is running. I also modified my rcscript to clean out this directory whenever the daemon is started. A lot of work to make up for an inexplicable oversight in OpenVPN's design. Thanks again. – succulent_headcrab Jun 06 '17 at 16:29