| Message ID | 20190409143438.25348-2-soltys@ziu.info |
|---|---|
| State | Accepted |
| Headers | show |
| Series | --capath/--crl-verify description update | expand |
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
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
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 ?
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.
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>
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 --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
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(-)