Todo #9915
closedConvert OpenVPN to CAPath
100%
Description
While investigating #9889, I found that OpenVPN recently introduced a new style of specifying CA and CRLs in a single directive, capath
:
--capath dir Directory containing trusted certificates (CAs and CRLs). Not available with mbed TLS. CAs in the capath directory are expected to be named <hash>.<n>. CRLs are expected to be named <hash>.r<n>. See the -CApath option of openssl verify , and the -hash option of openssl x509 and openssl crl for more information. Similarly to the --crl-verify option CRLs are not mandatory - OpenVPN will log the usual warning in the logs if the relevant CRL is missing, but the connection will be allowed.
This is the same format supported natively in OpenSSL with its -CAPath
option, and shares its behavior. There is already some code in source:src/etc/inc/certs.inc in ca_setup_trust_store()
which generates CA files in this format, which could be generalized and extended to support CRLs.
We should test and if it works sufficiently, convert OpenVPN to use this new syntax which is a more reliable way to structure the CA for use by OpenVPN/OpenSSL.
The main question seems to be whether or not revoking a certificate also requires the server to be reloaded or not. With crl-verify
, the file is re-read for each client reconnect.
Updated by Jim Pingle almost 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 348c2af1671d8f11c5d9ca67a32cbb28940ef19a.
Updated by Jim Pingle almost 5 years ago
While the new structure functions well at startup, it does appear as though the CRL status is cached at startup. When the CRL files are updated, it doesn't look like they are re-read, and revoked clients can still connect. Additionally, there is still no change with respect to #9889 -- certificates revoked by an intermediate CA are still not recognized as revoked.
Nov 26 10:36:44 clara openvpn[26294]: 172.21.32.87:1194 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=jimp Nov 26 10:36:44 clara openvpn[26294]: 172.21.32.87:1194 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=chain-intermediate-ca Nov 26 10:36:44 clara openvpn[26294]: 172.21.32.87:1194 VERIFY WARNING: depth=2, unable to get certificate CRL: CN=chain-root-ca
The new overall structure is better, though, so rather than back everything out, I can switch it back to the old ca/crl-verify style for the time being.
Updated by Jim Pingle almost 5 years ago
- Status changed from Feedback to In Progress
Something else to consider is to increment the CRL suffix number (e.g. r0 -> r1 -> r2), which may trick OpenSSL into verifying. Worth a test before backing out.
https://community.openvpn.net/openvpn/ticket/623
https://mta.openssl.org/pipermail/openssl-commits/2016-July/009218.html
Updated by Jim Pingle almost 5 years ago
That method does work to update CRLs, so I'll adjust the code to work that way.
Still doesn't work for intermediate CRLs, but it's better than before in other ways.
Updated by Jim Pingle almost 5 years ago
- Status changed from In Progress to Feedback
Applied in changeset 475d712b910e197256c06634051e1ad75be4bdfe.
Updated by Jim Pingle almost 5 years ago
- Status changed from Feedback to Resolved
OpenVPN has been using capath on snapshots for a month and so far, no negative reactions. Everything is working as intended.
If new problems are discovered, they can be handled with separate issues.