After updating to OpenVPN v2.4.7 and OpenSSL 1.1.1c on Arch Linux, I can't connect to the server I previously used:
➜ untangle-vpn sudo openvpn --verb 11 --config ./config.ovpn
Fri Jun 7 21:46:11 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
Fri Jun 7 21:46:11 2019 library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10
Fri Jun 7 21:46:11 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XX.XXX.XXX.XXX:XXXX
Fri Jun 7 21:46:11 2019 UDP link local: (not bound)
Fri Jun 7 21:46:11 2019 UDP link remote: [AF_INET]XX.XXX.XXX.XXX:XXXX
Fri Jun 7 21:46:11 2019 Certificate does not have key usage extension
Fri Jun 7 21:46:11 2019 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Fri Jun 7 21:46:11 2019 TLS_ERROR: BIO read tls_read_plaintext error
Fri Jun 7 21:46:11 2019 TLS Error: TLS object -> incoming plaintext read error
Fri Jun 7 21:46:11 2019 TLS Error: TLS handshake failedThe people running our VPN server seem unlikely to re-issue my certificates with key usage extension any time soon.
Can I skip key usage extension check somehow?
My current config:
➜ untangle-vpn head -n 15 ./config.ovpn
client
resolv-retry 20
keepalive 10 60
nobind
mute-replay-warnings
remote-cert-tls server
comp-lzo
verb 1
persist-key
persist-tun
explicit-exit-notify 1
dev tun
proto udp
port 1194
cipher AES-128-CBC 1 3 Answers
Yes, remove the remote-cert-tls server option.
(Or, if you want to still check the "Extended Key Usage" extension, but not "Key Usage", replace the option with remote-cert-eku "TLS Web Server Authentication" as shown in openvpn's manual page.)
--remote-cert-tls client|server Require that peer certificate was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules. [...] The --remote-cert-tls server option is equivalent to --remote-cert-ku --remote-cert-eku "TLS Web Server Authentication" 4 I realized, after posting the below comment under the author's question, it may prove helpful to offer the code required to generate the server and client certs properly with the correct EKUs.
Removing the EKU requirement is a bad idea all around and undermines the security of the VPN - it is not advised under any circumstance. If the "people running our VPN server" is a 3rd party, find another vendor, as they clearly don't understand what they're doing. If the individuals are in your company, address it directly with them to properly configure the VPN server, as they also don't understand what they're doing. The EKU in question prevents MITM attacks. Please see extendedKeyUsage section in this answer for the EKU definitions
I cover V3 Profiles, KUs, and EKUs within the openssl.cnf in more depth within this answer
VPN Server:
[ v3_vpn_server ]
basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = critical, serverAuth
subjectAltName = @alt_vpn_serverkeyUsage:nonRepudiation: Prevents signing entity from falsely denying some actiondigitalSignature: Used for entity and data origin authentication with integrityThe following two KUs allows use of all ciphers:
Choosing one or the other, and not both, limits the ciphers the server can utilizekeyEncipherment: Used to encrypt symmetric key, which is then transferred to targetkeyAgreement: Enables use of key agreement to establish symmetric key with target
extendedKeuUsage:serverAuth: Server authentication, distinguishing a server clients authenticate against
Required KUs:digitalSignature,keyEnciphermentorkeyAgreement
VPN Client:
[ v3_vpn_client ]
basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, clientAuth
subjectAltName = @alt_vpn_clientextendedKeuUsage:clientAuth: Client authentication, distinguishing a client as a client only
Required KUs:digitalSignatureand/orkeyAgreement
Something changed on openssl-1.1.0j regarding MD5 (they disabled support by default), so it needs to be enabled.
I’ve added line Environment="OPENSSLENABLEMD5VERIFY=1 NSSHASHALGSUPPORT=+MD5" under [Service] section in file /usr/lib/systemd/system/openvpn@.service
[Unit]
Description=OpenVPN Robust And Highly Flexible Tunneling Application (Config: %I)
After=network.target
PartOf=openvpn.target
[Service]
Environment="OPENSSL_ENABLE_MD5_VERIFY=1 NSS_HASH_ALG_SUPPORT=+MD5"
PrivateTmp=true
Type=forking
PIDFile=/var/run/openvpn/%i.pid
ExecStart=/usr/sbin/openvpn --daemon --writepid /run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf
[Install]
WantedBy=openvpn.targetAlso I removed the ns-cert-type or remote-cert-tls options from OpenVPN client configuration file
client.conf
#ns-cert-type server
#remote-cert-tls server
cert /etc/openvpn/client/yateucn_client.crt 1