diff mbox series

[Openvpn-devel,1/1] man: correct the description of --capath and --crl-verify regarding CRLs

Message ID 20190409143438.25348-2-soltys@ziu.info
State Accepted
Headers
Series --capath/--crl-verify description update |

Commit Message

Michal Soltys April 9, 2019, 4:34 a.m. UTC 
  The man page states that when using --capath, the user is required to
provide CRLs for CAs. This is not true and providing CRLs is optional -
both in case of --capath as well as --crl-verify options. When relevant
CRL is not found OpenVPN simply logs the warning in the logs while
allowing the connection, e.g.:

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

This patch clarifies the behavior.

Signed-off-by: Michal Soltys <soltys@ziu.info>
---
 doc/openvpn.8 | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

Comments

Arne Schwabe April 9, 2019, 10:24 p.m. UTC | #1 
Am 09.04.19 um 16:34 schrieb Michal Soltys:
> The man page states that when using --capath, the user is required to
> provide CRLs for CAs. This is not true and providing CRLs is optional -
> both in case of --capath as well as --crl-verify options. When relevant
> CRL is not found OpenVPN simply logs the warning in the logs while
> allowing the connection, e.g.:
> 

On my server the connection used to fail without CRLs. I just retested
this and with OpenSSL 1.1.1 there is not even a warning, so I am really
confused now.

Arne
Michal Soltys April 10, 2019, 3:45 a.m. UTC | #2 
On 4/10/19 10:24 AM, Arne Schwabe wrote:
> Am 09.04.19 um 16:34 schrieb Michal Soltys:
>> The man page states that when using --capath, the user is required to
>> provide CRLs for CAs. This is not true and providing CRLs is optional -
>> both in case of --capath as well as --crl-verify options. When relevant
>> CRL is not found OpenVPN simply logs the warning in the logs while
>> allowing the connection, e.g.:
>>
> 
> On my server the connection used to fail without CRLs. I just retested
> this and with OpenSSL 1.1.1 there is not even a warning, so I am really
> confused now.
> 
> Arne

Hmm, I do have warnings (with 1.1.1 and 1.1.0), at least at --verb 3:

Wed Apr 10 15:42:44 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Wed Apr 10 15:42:44 2019 library versions: OpenSSL 1.1.1b  26 Feb 2019, LZO 2.10
Wed Apr 10 15:42:44 2019 Diffie-Hellman initialized with 1024 bit key
Wed Apr 10 15:42:44 2019 WARNING: experimental option --capath /home/nozo/openvpn-test/certs
Wed Apr 10 15:42:44 2019 ECDH curve prime256v1 added
Wed Apr 10 15:42:44 2019 TUN/TAP device tunovn opened
Wed Apr 10 15:42:44 2019 TUN/TAP TX queue length set to 100
Wed Apr 10 15:42:44 2019 /usr/bin/ip link set dev tunovn up mtu 1500
Wed Apr 10 15:42:44 2019 /usr/bin/ip addr add dev tunovn 10.15.30.1/24 broadcast 10.15.30.255
Wed Apr 10 15:42:44 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Apr 10 15:42:44 2019 UDPv4 link local (bound): [AF_INET][undef]:1194
Wed Apr 10 15:42:44 2019 UDPv4 link remote: [AF_UNSPEC]
Wed Apr 10 15:42:44 2019 MULTI: multi_init called, r=256 v=256
Wed Apr 10 15:42:44 2019 IFCONFIG POOL: base=10.15.30.2 size=252, ipv6=0
Wed Apr 10 15:42:44 2019 Initialization Sequence Completed
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 TLS: Initial packet from [AF_INET]192.168.77.99:54604, sid=67ca0e76 da568cb7
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY WARNING: depth=0, unable to get certificate CRL: C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=Touki, CN=msl
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY WARNING: depth=1, unable to get certificate CRL: C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=IT, CN=TouK Intermediate X1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY WARNING: depth=2, unable to get certificate CRL: C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=IT, CN=TouK Root X1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY OK: depth=2, C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=IT, CN=TouK Root X1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY OK: depth=1, C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=IT, CN=TouK Intermediate X1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 VERIFY OK: depth=0, C=PL, ST=Mazowieckie, L=Warszawa, O=TouK sp. z o.o. s.k.a., OU=Touki, CN=msl
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_VER=2.4.7
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_PLAT=linux
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_PROTO=2
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_NCP=2
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_LZ4=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_LZ4v2=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_LZO=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_COMP_STUB=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_COMP_STUBv2=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 peer info: IV_TCPNL=1
Wed Apr 10 15:42:48 2019 192.168.77.99:54604 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Michal Soltys April 10, 2019, 3:51 a.m. UTC | #3 
On 4/10/19 3:45 PM, Michal Soltys wrote:
> On 4/10/19 10:24 AM, Arne Schwabe wrote:
>> Am 09.04.19 um 16:34 schrieb Michal Soltys:
>>> The man page states that when using --capath, the user is required to
>>> provide CRLs for CAs. This is not true and providing CRLs is optional -
>>> both in case of --capath as well as --crl-verify options. When relevant
>>> CRL is not found OpenVPN simply logs the warning in the logs while
>>> allowing the connection, e.g.:
>>>
>>
>> On my server the connection used to fail without CRLs. I just retested
>> this and with OpenSSL 1.1.1 there is not even a warning, so I am really
>> confused now.
>>
>> Arne
> 
> Hmm, I do have warnings (with 1.1.1 and 1.1.0), at least at --verb 3:
> 

For the record, --verb 3 or stronger is required for those warnings to 
be logged. 2 will only record verify success, 1 won't log any of those.

BTW, is this still considered an experimental option ?
haixiao.yan.cn--- via Openvpn-devel June 12, 2019, 10:49 p.m. UTC | #4 
On 19/04/10 15:51, Michal Soltys wrote:
> On 4/10/19 3:45 PM, Michal Soltys wrote:
>> On 4/10/19 10:24 AM, Arne Schwabe wrote:
>>> Am 09.04.19 um 16:34 schrieb Michal Soltys:
>>>> The man page states that when using --capath, the user is required to
>>>> provide CRLs for CAs. This is not true and providing CRLs is optional -
>>>> both in case of --capath as well as --crl-verify options. When relevant
>>>> CRL is not found OpenVPN simply logs the warning in the logs while
>>>> allowing the connection, e.g.:
>>>>
>>>
>>> On my server the connection used to fail without CRLs. I just retested
>>> this and with OpenSSL 1.1.1 there is not even a warning, so I am really
>>> confused now.
>>>
>>> Arne
>>
>> Hmm, I do have warnings (with 1.1.1 and 1.1.0), at least at --verb 3:
>>
> 
> For the record, --verb 3 or stronger is required for those warnings to 
> be logged. 2 will only record verify success, 1 won't log any of those.
> 


Anyway, it's beeen a bit since that thread - any chance to update the 
docs about this ? I can redo/rebase the patch as necessary.
Arne Schwabe June 14, 2019, 12:15 a.m. UTC | #5 
Am 09.04.19 um 16:34 schrieb Michal Soltys:
> The man page states that when using --capath, the user is required to
> provide CRLs for CAs. This is not true and providing CRLs is optional -
> both in case of --capath as well as --crl-verify options. When relevant
> CRL is not found OpenVPN simply logs the warning in the logs while
> allowing the connection, e.g.:

I cannot get my OpenVPN to fail without CRLs, so it might be change in
OpenSSL or OpenVPN but this patch changes to documentation to reflect
current behaviour, so

Acked-By: Arne Schwabe <arne@rfc2549.org>
Gert Doering June 23, 2019, 9:12 a.m. UTC | #6 
Your patch has been applied to the master and release/2.4 branch.

Fixed one "hash>.<n>" typo on the fly.

commit b3cfc43da3583ae8aa761beb29f016311b2ba64f (master)
commit 3f72b838fd505dbd898cced364a655eef08a8c27 (release/2.4)
Author: Michal Soltys
Date:   Tue Apr 9 16:34:38 2019 +0200

     man: correct the description of --capath and --crl-verify regarding CRLs

     Signed-off-by: Michal Soltys <soltys@ziu.info>
     Acked-by: Arne Schwabe <arne@rfc2549.org>
     Message-Id: <20190409143438.25348-2-soltys@ziu.info>
     URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18343.html
     Signed-off-by: Gert Doering <gert@greenie.muc.de>


--
kind regards,

Gert Doering
diff mbox series

Patch

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index ce440447..a77866c7 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4598,11 +4598,8 @@  they are distributed with OpenVPN, they are totally insecure.
 Directory containing trusted certificates (CAs and CRLs).
 Not available with mbed TLS.
 
-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
+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
@@ -4613,6 +4610,11 @@  option of
 and
 .B openssl crl
 for more information.
+
+Similarly to the
+.B \-\-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.
 .\"*********************************************************
 .TP
 .B \-\-dh file
@@ -5685,6 +5687,10 @@  overall integrity of the PKI.
 The only time when it would be necessary to rebuild the entire PKI from scratch would be
 if the root certificate key itself was compromised.
 
+The option is not mandatory \- if the relevant CRL is missing, OpenVPN will log
+a warning in the logs \- e.g. "\fIVERIFY WARNING: depth=0, unable to get
+certificate CRL\fR" \- but the connection will be allowed.
+
 If the optional
 .B dir
 flag is specified, enable a different mode where