4

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 failed

The 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
  • 1
    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" are 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
    – JW0914
    Nov 18, 2019 at 13:19

3 Answers 3

6

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
  • Thanks! Because all of these are Chinese to me, this "keyUsage" is an extra field on server certificate created from openssl? What is "your server certificates with the keyUsage set to digitalSignature, keyEncipherment and the extendedKeyUsage to serverAuth"? Any link? Any command line with openssl?
    – Chameleon
    Sep 10, 2019 at 15:09
  • Removing the EKU requirement is a bad idea all around and undermines the security of the VPN... it is not advised under any circumstance. The individuals who configured the VPN server did so improperly and, clearly, don't understand what they're doing. The EKU in question prevents MITM attacks.
    – JW0914
    Nov 18, 2019 at 13:15
  • @JW0914: Do you mean e.g. another client using their own 'client' certificate from the same VPN CA in place of the real server certificate? Nov 18, 2019 at 14:05
  • @grawity Yes. The server's EKU specifies it as a server and all clients' EKU identifies them as a client, allowing a client to only ever act as a client. With those two EKUs missing, any client can act a server, allowing for a MITM attack against all clients signed by the same CA who are not enforcing the serverAuth and clientAuth EKUs. Since client configs are generally not private or individualized, with the same config generally disseminated to all clients, it doesn't take a lot of effort to have one of those clients initiate a MITM attack against another client.
    – JW0914
    Nov 18, 2019 at 14:19
8

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_server
  • keyUsage:
    • nonRepudiation: Prevents signing entity from falsely denying some action
    • digitalSignature: Used for entity and data origin authentication with integrity

      The following two KUs allows use of all ciphers:
      Choosing one or the other, and not both, limits the ciphers the server can utilize
    • keyEncipherment: Used to encrypt symmetric key, which is then transferred to target
    • keyAgreement: Enables use of key agreement to establish symmetric key with target

  • extendedKeuUsage:
    • serverAuth: Server authentication, distinguishing a server clients authenticate against
      Required KUs: digitalSignature, keyEncipherment or keyAgreement

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_client
  • extendedKeuUsage:
    • clientAuth: Client authentication, distinguishing a client as a client only
      Required KUs: digitalSignature and/or keyAgreement
0

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/[email protected]

[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.target

Also 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
  • Removing the EKU requirement is a bad idea all around and undermines the security of the VPN - it is not advised under any circumstance, as the EKUs in question prevents MITM attacks (please see extendedKeyUsage section for the EKU definitions). MD5 shouldn't be used, as it's not a secure hashing mechanism; instead, use SHA256 || SHA512 and if the server or client uses an x64 CPU, SHA512 should be used since x64 CPUs process SHA512 faster than SHA256.
    – JW0914
    Jun 8, 2021 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .