capath usage either unclear or dysfunctional

[ikrabbe]

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.

[ikrabbe]

ah, sorry, the openssl command line is

openssl verify --CApath "path_to_my_certificates" server.cert

the answer is

server.cert:OK

[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?

[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.

[Gert Döring]

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

[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.

[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

[Steffan Karger]

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

[Steffan Karger]

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

[ikrabbe]

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