Clarify --capath option in manpage
PATCH 1/1 Clarify --capath option in manpage
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
Attached are patches for the master and release/2.3 branches. The only difference is that in the master patch, a line referencing the requirement for OpenSSL 0.9.7 is removed, since master already requires OpenSSL >= 0.9.8.
-Steffan
From 96e564e113cc26adf22e5d4b51d5754858610c3e Mon Sep 17 00:00:00 2001
From: Steffan Karger <[email protected]...>
Date: Sun, 24 May 2015 11:20:11 +0200
Subject: [PATCH] Clarify --capath option in manpage
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
--- doc/openvpn.8 | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
doc/openvpn.8 +16 -0
@@ -4209,6 +4209,22 @@ they are distributed with OpenVPN, they are totally insecure. Directory containing trusted certificates (CAs and CRLs). Available with OpenSSL version >= 0.9.7 dev. Not available with PolarSSL. + +When using the +.B \-\-capath +option, you are required to supply valid CRLs for the CAs too. CAs in the +capath directory are expected to be named <hash>.<n>. CRLs are expected to +be named <hash>.r<n>. See the +.B -CApath +option of +.B openssl verify +, and the +.B -hash +option of +.B openssl x509 +and +.B openssl crl +for more information. .\"********************************************************* .TP .B \-\-dh file
Signature · 1 line
2.1.4
From 3626088e146dbf959d7ec73f4e7cc5ab24c1ad57 Mon Sep 17 00:00:00 2001
From: Steffan Karger <[email protected]...>
Date: Sun, 24 May 2015 11:18:34 +0200
Subject: [PATCH] Clarify --capath option in manpage
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
--- doc/openvpn.8 | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
doc/openvpn.8 +16 -1
@@ -4263,8 +4263,23 @@ they are distributed with OpenVPN, they are totally insecure. .TP .B \-\-capath dir Directory containing trusted certificates (CAs and CRLs). -Available with OpenSSL version >= 0.9.7 dev. Not available with PolarSSL. + +When using the +.B \-\-capath +option, you are required to supply valid CRLs for the CAs too. CAs in the +capath directory are expected to be named <hash>.<n>. CRLs are expected to +be named <hash>.r<n>. See the +.B -CApath +option of +.B openssl verify +, and the +.B -hash +option of +.B openssl x509 +and +.B openssl crl +for more information. .\"********************************************************* .TP .B \-\-dh file
Signature · 1 line
2.1.4
Your patch has been applied to the master branch.
commit f4684ff2b5622a26c7c2e620e789b7dca8cfd778
Author: Steffan Karger Date: Sun May 24 11:45:40 2015 +0200
Clarify --capath option in manpage
Signed-off-by: Steffan Karger <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9732
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering
Your patch has been applied to the release/2.3 branch.
commit 1009df7d51f3fb7f898b2155aa62b8f0336e49e6
Author: Steffan Karger Date: Sun May 24 11:45:40 2015 +0200
Clarify --capath option in manpage
Signed-off-by: Steffan Karger <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9732
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering
Hi,
Quoted 4 lines · Steffan Karger
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
Attached are patches for the master and release/2.3 branches. The only difference is that in the master patch, a line referencing the requirement for OpenSSL 0.9.7 is removed, since master already requires OpenSSL >= 0.9.8.
I intend to NACK this patch - AFAIK it is *not* required to use .r0 CRL files with --capath. You can run your setup perfectly fine without them (last time I checked).
However, *IF* one wants to use CRL files in combination with --capath then you must supply .r0 files .
JJK
Hi Jan Just,
Quoted 10 lines · Jan Just Keijser
Quoted 8 lines · Steffan Karger
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
Attached are patches for the master and release/2.3 branches. The only difference is that in the master patch, a line referencing the requirement for OpenSSL 0.9.7 is removed, since master already requires OpenSSL >= 0.9.8.
Quoted 5 lines
I intend to NACK this patch - AFAIK it is *not* required to use .r0 CRL files with --capath.
You can run your setup perfectly fine without them (last time I checked). However, *IF* one wants to use CRL files in combination with --capath then you must supply .r0 files .
Hmm, interesting. I actually tested this in response to trac ticket #422 [0], where the users complains about --capath not working because of an error "VERIFY ERROR: depth=0, error=unable to get certificate CRL". My test setup with --capath instead of --ca resulted in the same behaviour, until I provided a CRL. Since --capath basically makes sense for multiple CAs, and it is not possible to provide multiple CRL files through --crl-verify, I decided pointing the users at the '<hash>.r<n>' files was the best way to go.
When using --capath, our code does (ssl_openssl.c:955 in master):
X509_STORE_set_flags (store, X509_V_FLAG_CRL_CHECK |
X509_V_FLAG_CRL_CHECK_ALL);
and the OpenSSL manpages seems to confirm that will result in the behaviour reported in trac #422, and in my tests:
X509_V_FLAG_CRL_CHECK enables CRL checking for the certificate chain leaf certificate. An error occurs if a suitable CRL cannot be found.
X509_V_FLAG_CRL_CHECK_ALL enables CRL checking for the entire certificate chain.
That said, I would not be surprised if there is some catch here that I missed. So I'm very interested to hear it if that is the case.
-Steffan
Hi Stefan,
Quoted 13 lines · Steffan Karger
Hi Jan Just,
Quoted 10 lines · Jan Just Keijser
Quoted 8 lines · Steffan Karger
Prevent confusion as described in trac #422 by better explaining the behaviour of --capath, and providing pointers to relevant openssl man pages.
Attached are patches for the master and release/2.3 branches. The only difference is that in the master patch, a line referencing the requirement for OpenSSL 0.9.7 is removed, since master already requires OpenSSL >= 0.9.8.
Quoted 8 lines
Quoted 5 lines
I intend to NACK this patch - AFAIK it is *not* required to use .r0 CRL files with --capath.
You can run your setup perfectly fine without them (last time I checked). However, *IF* one wants to use CRL files in combination with --capath then you must supply .r0 files .Hmm, interesting. I actually tested this in response to trac ticket #422 [0], where the users complains about --capath not working because of an error "VERIFY ERROR: depth=0, error=unable to get certificate CRL". My test setup with --capath instead of --ca resulted in the same behaviour, until I provided a CRL. Since --capath basically makes sense for multiple CAs, and it is not possible to provide multiple CRL files through --crl-verify, I decided pointing the users at the '<hash>.r<n>' files was the best way to go.
actually, stacked CRL files are supported by OpenSSL (> 0.9.8) so support for this is fairly simple.
Quoted 7 lines
When using --capath, our code does (ssl_openssl.c:955 in master):
X509_STORE_set_flags (store, X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);and the OpenSSL manpages seems to confirm that will result in the behaviour reported in trac #422, and in my tests:
Quoted 8 lines
X509_V_FLAG_CRL_CHECKenables CRL checking for the certificate chain leaf certificate. An error occurs if a suitable CRL cannot be found.
X509_V_FLAG_CRL_CHECK_ALLenables CRL checking for the entire certificate chain.That said, I would not be surprised if there is some catch here that I missed. So I'm very interested to hear it if that is the case.
I missed a catch here: I had a server running openvpn 2.2 which did support this - but that's because I added a patch to OpenVPN myself :( (not barfing on a missing CRL is an Openssl callback function of ~ 6 lines).
So, ACK to the patch afterall, although we could discuss whether
a) we want to support stacked CRLs (does PolarSSL support this?)
b) we want to support --capath *without* CRLs (relatively short patch).
Sorry about the noise,
JJK
Quoted 1 line · Jan Just Keijser
So, ACK to the patch afterall, although we could discuss whether
Thanks for the clarification. Let's discuss!
Quoted 1 line
a) we want to support stacked CRLs (does PolarSSL support this?)
I'll assume that 'stacked CRLs' means multiple (PEM?) CRLs concatenated into a single file.
Both OpenSSL and PolarSSL are capable of dealing with this, but we currently don't really use the crypto library CRL checking code for --crl-verify. Instead, we have our own x509_verify_crl() function that loads and checks the supplied CRL on every connect. Our implementation of that function does not support stacked CRLs in both our OpenSSL and PolarSSL builds.
The real solution here is probably to let the crypto library do the CRL handling. Adriaan actually started on that during the latest Munich hackathon, but ended up in a bathtub rather quickly [0]. I had a similar experience a little longer ago. The tricky part, iirc, is to figure out when en how to reload the CRL. But we probably both did not truly take the time to 'dive in' ;)
Quoted 1 line
b) we want to support --capath *without* CRLs (relatively short patch).
Yes, I considered that too, but decided not to propose it and see if anyone else would suggest it. So thank you ;) Perhaps a --crl-soft-fail option? The other side of that knife would be that we can introduce stricter CRL checking for --crl-verify too. For example, our current implementation of x509_verify_crl() will happily accept clients if you supply the wrong CRL (but fail if you supply an invalid CRL). That strikes me as weird. Most clients I know of resolve that by implementing their own CRL checking on some plugin or script.
I don't run large OpenVPN setups myself, so I am very much interested to know how 'enterprise users' of OpenVPN deal with this kind of thing, and what they would like.
-Steffan
[0] http://img.pandawhale.com/post-10513-Code-Refactoring-Cat-in-Bathtu-U295.gif
