Key Usage Checks Fail on User/Client Certificate

datdamnmachine

I set up OpenVPN server with Remote Access (SSL/TLS + User Auth). I was using the following parameters on the server and client:

Server:


remote-cert-tls client

Client:


remote-cert-tls server

With this, I found I was getting these errors:


Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 Validating certificate key usage
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 ++ Certificate has key usage 00e0, expects 0080
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 ++ Certificate has key usage 00e0, expects 0008
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 ++ Certificate has key usage 00e0, expects 0088
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 VERIFY KU ERROR
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 TLS_ERROR: BIO read tls_read_plaintext error
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 TLS Error: TLS object -> incoming plaintext read error
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 TLS Error: TLS handshake failed
Apr 9 20:12:03	openvpn	37035	174.255.204.127:16021 SIGUSR1[soft,tls-error] received, client-instance restarting

If I disabled the server-side configuration checking the client certificate, it would work. Hat tip to the following links for leading me in the right direction:

https://www.v13.gr/blog/?p=386

https://redmine.pfsense.org/issues/6877

https://airvpn.org/topic/11245-how-to-set-up-pfsense-21-for-airvpn/

These articles led me to the OpenVPN man page for 2.3 (which had more information regarding the "remote-cert-tls" commands)

https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

–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.

This is a useful security option for clients, to ensure that the host they connect to is a designated server.

The --remote-cert-tls client option is equivalent to --remote-cert-ku 80 08 88 --remote-cert-eku "TLS Web Client Authentication"

The key usage is digitalSignature and/or keyAgreement.

The --remote-cert-tls server option is equivalent to --remote-cert-ku a0 88 --remote-cert-eku "TLS Web Server Authentication"

The key usage is digitalSignature and ( keyEncipherment or keyAgreement ).

This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --remote-cert-tls, --verify-x509-name, or --tls-verify.

As the man page suggests, these are man-in-the-middle mitigation checks. In my case, the client is able to validate the server certificate but not the other way around. Basically, the "remote-cert-tls client" command is hard coded to check for the remote KU of 80 08 88. See the link below I posted previously for their meanings:

https://www.v13.gr/blog/?p=386

When I checked KU of the client cert it had this:


Digital Signature, Non-Repudiation, Key Encipherment (e0)

Hence, the errors from above. It is expecting a KU of 80 08 88 but, instead, the certificate was using a KU of e0.

Now, for the solution. In order to solve, I had to remove the "remote-cert-tls client" command from the server and replace it with this:


remote-cert-ku e0
remote-cert-eku "TLS Web Client Authentication"

This now works as it tells the server to check for the KU of e0 and still performs the EKU check for "TLS Web Client Authentication". I hope this information helps others. Now…

My question. These certificates were created from Pfsense. Why would the certificate creation NOT create user/client certificates with the appropriate KU for OpenVPN to perform the "remote-cert-tls client" checks? Is this a bug/gotcha or a matter of an OpenVPN feature not playing right with Pfsense's certificate creation facilities or the reverse? I've also read in other posts that this could be due to OpenVPN's tighter integration of EasyRSA and that those certs would likely be created appropriately.