Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#422 closed Bug / Defect (fixed)

capath usage either unclear or dysfunctional

Reported by: ikrabbe Owned by: Steffan Karger
Priority: major Milestone: release 2.3.7
Component: Certificates Version: OpenVPN 2.3.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger

Description

I connect to server using config files. Until I experienced timed out validation periods of my self managed ca, I used the 'ca' option to specify the ca certificate to check the server certificate against, in the client configuration file.
Now I want to use the 'capath' option to be able to use several versions of the same certificate, when I renew my ca certificate.

When I check the server certificate with

openssl --CApath "path_to_my_certificates" server.cert

I get an ok, after hashing the "path_to_my_ca_certificates".

But using capath in the openvpn configuration does not work with the message

"Mon Jul 7 08:43:41 2014 VERIFY ERROR: depth=0, error=unable to get certificate CRL: [DETAILS]"

using "ca" works with the same configuration and the hashed certificate files in the capath I chose above.

So I would say, the capath option just does not work.

Change History (11)

comment:1 Changed 6 years ago by ikrabbe

ah, sorry, the openssl command line is

openssl verify --CApath "path_to_my_certificates" server.cert

the answer is

server.cert:OK

comment:2 in reply to:  1 ; Changed 6 years ago by Samuli Seppänen

Replying to ikrabbe:

ah, sorry, the openssl command line is

openssl verify --CApath "path_to_my_certificates" server.cert

the answer is

server.cert:OK

Are you saying that this bug was a false positive? Shall I close it?

comment:3 Changed 6 years ago by Steffan Karger

Component: OpenVPN ConnectCertificates

comment:4 in reply to:  2 Changed 6 years ago by khms

Replying to samuli:

Replying to ikrabbe:

ah, sorry, the openssl command line is

openssl verify --CApath "path_to_my_certificates" server.cert

the answer is

server.cert:OK

Are you saying that this bug was a false positive? Shall I close it?

Looks to me like ikrabbe is simply correcting the openssl command he gave (starts with "verify").

For that matter, I seem to have the exact same problem.

comment:5 Changed 5 years ago by Gert Döring

Cc: Steffan Karger added

Steffan, any quick ideas? Is this supposed to work, to need special care and feeding, or known broken?

comment:6 Changed 5 years ago by Gert Döring

Milestone: release 2.3.8

comment:7 Changed 5 years ago by Steffan Karger

No, sorry, no immediate ideas. And tbh, there's other stuff that has higher priority to me, so this one will have to wait a little longer before I will try to fix it. Other are welcome to take a go at it though.

comment:8 Changed 5 years ago by Steffan Karger

Now that I look a bit closer, I think I do understand.

OpenVPN complains about not being able to find/retrieve the CRL specified in one of your (sub) CAs. (edit: ignore this previous text When using the capath option, you can't use the crl option to supply CRLs for all the CAs in the capath, so OpenVPN configures OpenSSL to automatically retrieve and check the CRLs listed in the CA certificate for you.) When using the capath option, OpenVPN enforces you also supply valid CRLs. To do so, put the CRLs in the capath dir too, name or linked as <hash>.r<n> (eg if your ca cert name/link is ffb84ff2.0, the crl name/link is ffb84ff2.r0).

I can can get the same behaviour from OpenSSL:

$ openssl verify -CApath /your/path -crl_check -crl_check_all server.crt
server.crt: C = KG, ST = NA, O = OpenVPN-TEST, CN = Test-Server, emailAddress = me@myhost.mydomain
error 3 at 0 depth lookup:unable to get certificate CRL

and fix it by supplying the crl

$ openssl verify -CApath /your/path -crl_check -crl_check_all -CRLfile ca.crl server.crt
server.crt: OK
Last edited 5 years ago by Steffan Karger (previous) (diff)

comment:9 Changed 5 years ago by Steffan Karger

Owner: set to Steffan Karger
Status: newaccepted

Recapping, the capath usage is indeed not very clear. To improve on that, I sent a patch to the openvpn-devel list:
http://thread.gmane.org/gmane.network.openvpn.devel/9732

comment:10 Changed 5 years ago by Steffan Karger

Milestone: release 2.3.8release 2.3.7
Resolution: fixed
Status: acceptedclosed

... and patches have been acked and merged:
https://github.com/OpenVPN/openvpn/commit/f4684ff (master)
https://github.com/OpenVPN/openvpn/commit/1009df7 (release/2.3)

comment:11 Changed 5 years ago by ikrabbe

Thousand thanks for the insight and the solution.
Thumbs up!

Note: See TracTickets for help on using tickets.