2

I'm running OpenVPN on a hardware router running OpenWRT. Every time a client connects I get the following error in the logs:

VERIFY WARNING: depth=0, unable to get certificate CRL

I've got a 2 level CA with both levels publishing CRLs and the merged CRL available on the router and OpenVPN making use of it.

I'm confused about why OpenVPN is trying to get the CRL at depth 0, which is the client certificate. It doesn't complain about depths 1 and 2 which indicates my CRL file is fine ...

marius-O
  • 135
  • 1
  • 5

1 Answers1

1

It seems that later versions of OpenVPN doesn't understand multiple PEM encoded CRLs in one file.

If you edit you CRL file so that it contains only the CRL of the client certificate issuing CA, you'll see that you won't get errors for depth=0 and will instead get an error for depth=1. You'll probably get the same results if you swap the order of the CRLs in your current file.

To resolve this on later versions of OpenVPN you should use the --capath:

--capath dir

Directory containing trusted certificates (CAs and CRLs). Not available with mbed TLS.

Place all your CA certificates and the CRLs generated by your CAs in a directory pointed to by the --capath option. Remember to remove the --ca option.

Run c_rehash <path to certs and CRLs> to generate a hash of the certificates and their CRLs.

Restart OpenVPN and you should find your logs are devoid of CRL warnings.

Note: You should never get an CRL warning for depth=2 (your root CA) as it will be a self-signed certificate and a CRL for one of those is pointless because it would be signed by itself. But it seems that if you omit the root CA's CRL, it shows a verify warning for itself (depth=2) as well as the certificate it issued (the intermediate CA at depth=1). It should only show a warning for the latter.

garethTheRed
  • 4,539
  • 14
  • 22
  • Is this a change in recent versions of OpenVPN? Ran it for about 4 years without such issues. Updated it a couple weeks back and boom ... – marius-O Oct 03 '18 at 17:33
  • It seems that CRL processing was changed in v2.4 to use the SSL library instead of internal. This may well be the cause of the change in operation. – garethTheRed Oct 03 '18 at 18:05
  • I can confirm that by swapping the CRLs around I get the warning for `depth=2`. Quite likely the `--capath` option would fix it all (maybe you've got a setup to test this assumption, as I don't have one handy), but that's not available in the OpenWrt build. Could you also please expand on your point that the CRL for a self-signed Root CA is pointless? Surely Root CAs should be able to revoke Intermediate CA certs... – marius-O Oct 03 '18 at 21:52
  • For the root CA CRL point - `depth = 2` is checking the root CA, which is pointless. `depth = 1` is the intermediate CA check, using a CRL _generated_ by the root CA. Similarly, `depth = 0`is the client being checked using a CRL _generated_ by your intermediate CA. The depth is the level being checked, not the level generating the CRL. – garethTheRed Oct 04 '18 at 06:31
  • Tested `--capath` and edited my answer. You could port-forward through OpenWRT to a VM running OpenVPN. Maybe that's the pragmatic solution? – garethTheRed Oct 04 '18 at 07:31
  • Apparently I'm too young in the community to mark as answer, but it indeed fixes the problem, even if it doesn't help my case much. My setup is for non-professional use so not that bothered with the warning itself, was trying to understand why it showed up. Thanks! – marius-O Oct 04 '18 at 21:35