6

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
Utgarda
  • 163

3 Answers3

10

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:

V3 Profiles

  • VPN Server:
    [ v3_vpn_server ]
    basicConstraints        = critical, CA:FALSE
    subjectKeyIdentifier    = hash
    authorityKeyIdentifier  = keyid:always, issuer:always
    keyUsage                = critical, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage        = critical, serverAuth
    subjectAltName          = @alt_vpn_server
    
    • keyUsage:
      • 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, 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
JW0914
  • 9,096
7

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"
grawity
  • 501,077
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/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.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
JW0914
  • 9,096
Paul
  • 13