openssl: upgrading from 1.1.1.e and 1.1.1.f causes openvpn connections using ssl to fail.

Apologies in advance for what is probably a poor report as it’s affected me only indirectly through openvpn.

moiraine$>openvpn --version
OpenVPN 2.4.8 [git:makepkg/3976acda9bf10b5e+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan  3 2020
library versions: OpenSSL 1.1.1e  17 Mar 2020, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
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_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes 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_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

^ Works

(1/1) Arming ConditionNeedsUpdate...

~/Downloads
moiraine$>openvpn --version
OpenVPN 2.4.8 [git:makepkg/3976acda9bf10b5e+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan  3 2020
library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
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_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes 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_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

Fails with error messages like this:

Apr 01 13:05:57 moiraine nm-openvpn[17321]: VERIFY ERROR: depth=0, error=unable to get local issuer certificate: O=**********, CN=*********************
Apr 01 13:05:57 moiraine nm-openvpn[17321]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr 01 13:05:57 moiraine nm-openvpn[17321]: TLS_ERROR: BIO read tls_read_plaintext error
Apr 01 13:05:57 moiraine nm-openvpn[17321]: TLS Error: TLS object -> incoming plaintext read error
Apr 01 13:05:57 moiraine nm-openvpn[17321]: TLS Error: TLS handshake failed

Perhaps this issue is caused downstream but I figured if rolling back openssl fixes things that’s probably where the issue lies.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 19 (13 by maintainers)

Commits related to this issue

Allow certificates with Basic Constraints CA:false, pathlen:0 Do not mark such certificates with EXFLAG_INVALID although they violate the RFC 5280, they are syntactically correct and openssl itself c... — committed to t8m/openssl by t8m 4 years ago
Allow certificates with Basic Constraints CA:false, pathlen:0 Do not mark such certificates with EXFLAG_INVALID although they violate the RFC 5280, they are syntactically correct and openssl itself c... — committed to openssl/openssl by t8m 4 years ago
Merged upstream 1.1.1h tag (#242) * Fix aesni_cbc_sha256_enc_avx2 backtrace info We store a secondary frame pointer info for the debugger in the red zone. This fixes a crash in the unwinder when... — committed to open-quantum-safe/openssl by christianpaquin 4 years ago

Most upvoted comments

The question is why openssl allows at all producing a certificate with the invalid CA:false

Because it is a foot-shoot-gun ?

bernd-edlinger on Apr 2, 2020

This is not a downstream packaging issue, commit https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 changed the validation result for self-signed certificates with invalid certificate extensions. To reproduce, generate a self-signed certificate with inconsistent extensions (with any OpenSSL version) using

openssl genrsa -out private.pem 4096
openssl req -new -key private.pem -out csr.pem
openssl x509 -req -signkey private.pem -in csr.pem -out cert.pem -extfile <(echo "basicConstraints=CA:FALSE,pathlen:0")

Now try verifying the generated certificate cert.pem using

openssl verify -CAfile cert.pem cert.pem

In OpenSSL 1.1.1e, this yields

cert.pem: OK

while OpenSSL 1.1.1f gives

C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
error 20 at 0 depth lookup: unable to get local issuer certificate
error cert.pem: verification failed

I suspect your VPN provider’s certificate has inconsistent extensions (and is therefore broken and should not be used), but previous OpenSSL versions didn’t report this because it is a self-signed certificate.

diabonas on Apr 1, 2020

Yeah, I know, I made a joke, at least I could laugh a while…

No worries, enjoy: https://lists.sr.ht/~jack/acme-dont-discuss/<874ku38utr.fsf%40jackkelly.name>

vdukhovni on Apr 2, 2020