Convert OpenVPN to CAPath
While investigating #9889, I found that OpenVPN recently introduced a new style of specifying CA and CRLs in a single directive,
--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.
Restructure OpenVPN settings directory layout
- Changed from /var/etc/openvpn[-csc]/<mode><id>.<file> to
- This keeps all settings for each client and server in a clean
- Move to CApath style CA structure for OpenVPN, which implements #9915
- Reused some code from trust store functions to generate the new CApath
format, since the layout is identical. Issue #4068
When refreshing CRLs, increment suffix, do not clean up. Fixes #9915
While here, fix a bug with refresh path.
#2 Updated by Jim Pingle 4 months 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: 172.21.32.87:1194 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=jimp Nov 26 10:36:44 clara openvpn: 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: 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.
#3 Updated by Jim Pingle 4 months 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.