Does not reload CRL files when are defined in CAPath

[hmolina]

Hi,
The openvpn server daemon does not reload the crl files to check the new connections, when I use to CAPath to define where are stored the ca and crl files.

This produce several problems:
1- IF i revoke a certificate, it is allowed to connect until I restart the openvpn daemon.
2- When the CRL initially loaded expires, the openvpn daemon rejects all new connections until restart.

[Gert Döring]

If it happens in 2.3.8, milestone cannot be "release 2.3.8"...

That said, syzzer, can you look into this? I remember discussions between you and janjust about capath, but can't remember crypto details :-)

[china]

Hi,
I've the same problem on 2.2 version

[Gert Döring]

Replying to china:

I've the same problem on 2.2 version

2.3.0 has been released nearly three years ago (January 2nd, 2013).

So if there is a bug in 2.3, it needs to be fixed, but we don't really care whether it's in 2.2 or not - please upgrade to something less archaic.

[hmolina]

The problem is in release 2.3.8 (sorry, if I mark 2.3.8 milestone, my fault).

Thanks in advance.

[Steffan Karger]

This seems to be standard OpenSSL behaviour. Iirc, a previous (shallow) search to teach openssl to reload the files from the folder did not yield any results. I recall jjk looked into this too at some point (CC'ing in).

I can't promise anything unfortunately; too much other higher-priority stuff on my list for now. So, patches welcome! Otherwise this will have to wait until I find enough spare cycles to spend on this.

[lytboris]

Replying to syzzer:

This seems to be standard OpenSSL behaviour. Iirc, a previous (shallow) search to teach openssl to reload the files from the folder did not yield any results.

Here's an approach OpenVswitch? uses - it just flushes old X509 store completely at some point:
​http://openvswitch.org/pipermail/dev/2011-June/009380.html

It seems the easiest way to do it is to flush it once a while when creating a session for a newly connected user.

[reators]

I stumbled over the same problem. I observed that OpenSSL lib tries to open the next hash file in the CRL row on every(!) verification of an incoming connection.
So this problem can be solved outside of OpenVPN, but an upstream patch of OpenSSL is needed for that (​https://mta.openssl.org/pipermail/openssl-commits/2016-July/009218.html) which is not included in current 1.0.2h version (so OpenSSL has to be patched manually currently).
I implemented the following working solution where OpenVPN doesn't have to be restarted and existing connections won't be harmed:

• On revocation of a cert a new hash link with the next revocation number for the crl has to be created. E.g. if b7fc194f.r0 exists the new link pointing to the CRL file is b7fc194f.r1. The name of the crl file itself doesn't have to be changed.
• The new link will be used for new incoming connections.
• The next revocation leads to the next link in the row, e.g. b7fc194f.r2
• In the start script of OpenVPN all those additional links are removed and replaced with the first one (e.g. b7fc194f.r0) as OpenSSL lib starts with reading the .r0 file and the others are not needed any more.

[Antonio Quartulli]

the --capath argument is is just a 1-to-1 matching with the openssl API/option and we can't really modify its behaviour unless we go through some hackish way.

However reators has provided a meaningful workaround that can be implemented to achieve a similar behaviour.

I am closing this ticket now as there is not much we can/want to do with it.