Opened 4 years ago
Closed 3 years ago
#1240 closed Bug / Defect (wontfix)
openvpn does not re-read CRLs upon client connect in "capath" mode
Reported by: | muszi | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | release 2.4.9 |
Component: | Certificates | Version: | OpenVPN 2.4.7 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | CRL |
Cc: |
Description
I also reported this bug in the Debian Bug Tracking System:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942097
Dear Maintainer,
openvpn does not re-read CRLs upon client connect in "capath" mode (that is,
a directory containing trusted CA certificates and CRLs).
I have a two-level CA setup (one root CA and one intermediate CA that emits
both server and client certificates). Please find attached the test
certificates I have used.
Here is my server config:
# daemon openvpn-server-client
user nobody
group nogroup
proto udp
key /etc/openvpn/server.key
cert /etc/openvpn/server.pem
capath /etc/openvpn/ca-certs
remote-cert-tls client
duplicate-cn
dh /etc/openvpn/dh2048.pem
cipher AES-256-CBC
float
lport 1194
dev tun
server 192.0.2.0 255.255.255.0
comp-lzo
passtos
keepalive 5 20
ping-timer-rem
persist-tun
persist-key
My client config (I guess it does not matter, but anyway):
# daemon openvpn-client-server
user nobody
group nogroup
proto udp
key /etc/openvpn/client.key
cert /etc/openvpn/client.pem
ca /etc/openvpn/ca-certs/ca-test-root.pem
verify-x509-name "example.com" name
remote-cert-tls server
cipher AES-256-CBC
remote localhost
resolv-retry 30
float
rport 1194
nobind
dev tun
client
comp-lzo
passtos
keepalive 5 20
ping-timer-rem
persist-tun
persist-key
I start the openvpn server with strace:
# strace -o /tmp/openvpn.strace openvpn --config config.server-client
... and watch openvpn accessing the capath directory in strace's log on another console:
# tail -f /tmp/openvpn.strace | grep -F "/etc/openvpn/ca-certs"
- first client connects *
stat("/etc/openvpn/ca-certs/b60149e5.0", {st_mode=S_IFREG|0644, st_size=7339, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/b60149e5.0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/b60149e5.1", 0x7ffd789d74c0) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.0", {st_mode=S_IFREG|0644, st_size=1870, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/7f67f311.0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/7f67f311.1", 0x7ffd789d74c0) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/b60149e5.r0", {st_mode=S_IFREG|0644, st_size=1003, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/b60149e5.r0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r0", {st_mode=S_IFREG|0644, st_size=991, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/7f67f311.r0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
- next client connects *
stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
- another client connects *
stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
(7f67f311 is the root CA, b60149e5 is the intermediate CA)
strace log shows that CRLs are read only when the first client connects.
When the next client connects, CRLs are attempted to access only using a wrong
filename ("*.r1" instead of "*.r0"), and open obviously fails.
This is a security problem if I later revoke a certificate, upload the new CRL,
but it does not have effect.
Please feel free to contact me if you need any further information.
--
Regards,
Zsolt
-- openvpn --version
OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@…>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.196 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-2, LC_CTYPE=en_US.ISO-8859-2 (charmap=ISO-8859-2), LANGUAGE=en_US.ISO-8859-2 (charmap=ISO-8859-2
Shell: /bin/sh linked to /usr/bin/dash
Init: none (chroot environment)
Versions of packages openvpn depends on:
ii debconf [debconf-2.0] 1.5.71
ii iproute2 4.20.0-2
ii libc6 2.28-10
ii liblz4-1 1.8.3-1
ii liblzo2-2 2.10-0.1
ii libpam0g 1.3.1-5
ii libpkcs11-helper1 1.25.1-1
ii libssl1.1 1.1.1d-0+deb10u1
ii libsystemd0 241-7~deb10u1
ii lsb-base 10.2019051400
Versions of packages openvpn recommends:
pn easy-rsa <none>
Versions of packages openvpn suggests:
ii openssl 1.1.1d-0+deb10u1
pn openvpn-systemd-resolved <none>
pn resolvconf <none>
-- debconf information:
openvpn/create_tun: false
Attachments (8)
Change History (17)
Changed 4 years ago by
Attachment: | ca-test-root.pem added |
---|
Changed 4 years ago by
Attachment: | ca-test.pem added |
---|
Changed 4 years ago by
Attachment: | crl-test-root.pem added |
---|
Changed 4 years ago by
Attachment: | crl-test.pem added |
---|
Changed 4 years ago by
Attachment: | server.key added |
---|
Changed 4 years ago by
Attachment: | server.pem added |
---|
Changed 4 years ago by
Attachment: | client.key added |
---|
Changed 4 years ago by
Attachment: | client.pem added |
---|
comment:1 Changed 4 years ago by
comment:4 Changed 4 years ago by
"CC" is "Carbon Copy", which is the simplest way for me to follow this ticket with email updates. Sorry for any misunderstanding.
comment:6 follow-up: 7 Changed 4 years ago by
Same bug as #1257?
As a workaround, you can put both CA certs into one file, which works from 2.4.9 up (and always worked for mbedtls builds).
comment:7 Changed 4 years ago by
Replying to Gert Döring:
Same bug as #1257?
As a workaround, you can put both CA certs into one file, which works from 2.4.9 up (and always worked for mbedtls builds).
I believe multiple CAs in one file has worked since forever, it's multiple CRLs (--crl-verify
) in one file that has been fixed recently.
comment:8 Changed 4 years ago by
I'm pretty sure it's a dup of #623, and the closing comment there sums up the situation pretty accurately (i.e. it's limitations of OpenSSL capath implementation).
Now that --crl-verify
support for multiple CRLs is fixed, I believe in most cases it should be just used instead.
In case you want flexibility, you can always write a --tls-verify
script. If you want performance as well, you can also write a plugin for it.
comment:9 Changed 3 years ago by
Milestone: | release 2.4.7 → release 2.4.9 |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Closing this bug. From what I understand, we can't do anything about it, and --crl-verify
got fixed in 2.4.9 to handle multiple CRLs.
Hi, just like to add this as it seems to confirm:
https://redmine.pfsense.org/issues/9915