Project

General

Profile

Actions

Todo #9915

closed

Convert OpenVPN to CAPath

Added by Jim Pingle almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
11/20/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:

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.

Actions #1

Updated by Jim Pingle almost 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #2

Updated by Jim Pingle almost 2 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.

Actions #3

Updated by Jim Pingle almost 2 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

Actions #4

Updated by Jim Pingle almost 2 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.

Actions #5

Updated by Jim Pingle almost 2 years ago

  • Status changed from In Progress to Feedback
Actions #6

Updated by Jim Pingle almost 2 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.

Actions

Also available in: Atom PDF