Opened 3 years ago

Closed 4 months ago

#623 closed Bug / Defect (wontfix)

Does not reload CRL files when are defined in CAPath

Reported by: hmolina Owned by: Steffan Karger
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.8 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: JJK

Description

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.

Change History (8)

comment:1 Changed 3 years ago by Gert Döring

Owner: set to Steffan Karger
Status: newassigned

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 :-)

comment:2 Changed 3 years ago by china

Hi,
I've the same problem on 2.2 version

comment:3 in reply to:  2 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by hmolina

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

Thanks in advance.

comment:5 Changed 3 years ago by Steffan Karger

Cc: JJK added
Milestone: release 2.3.8

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.

comment:6 in reply to:  5 Changed 3 years ago by 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.

comment:7 Changed 2 years ago by 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.

comment:8 Changed 4 months ago by Antonio

Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.