Having set up a new OpenVPN system, I suddenly struggled with the following error message in my syslog:

VERIFY ERROR: depth=0, error=unsupported certificate purpose: /C=....

At the first glance I thought that I had made a mistake when entering the common name. However, after some literature (originally this was written in the so-called “OpenVPN Howto”, which does not exist anymore; similar information is available to day at “Installing a valid SSL Web certificate in Access Server“, section “Certificate doesn’t match private key, unsupported certificate purpose”), it became clear that OpenVPN does not perform any checks on the Common Names by default. You may activate such a feature by using the statement tls-verify. However, I did not make use of it.
After a long search, the Linode Forum Thread “OpenVPN help… verify error depth=0?” brought the correct idea: As described in the section to prevent “Man-In-The-Middle” attack of the OpenVPN Howto, I had enabled my local Certification Authority (CA) to issue certificates with nsCertType set to server:

[...]
nsCertType = server
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

As I had automated the generation of keys via a small script, also the client certificate got created with this certificate type. However, OpenVPN apparently checks the usage type depending on the role your box is playing in the corresponding set up. This means:

• Use nsCertType=server certificates only for your OpenVPN server!
• Do not use nsCertType=server certificates for your OpenVPN clients!

If you obey these rules, you will not have a problem with the error message on an “Unsupported Certificate Purpose” at server side.

Edit on 2020-08-08:

The nsCertType logic was deprecated by OpenVPN and will be removed soon. In essence the option should be replaced with “remote-cert-tls”, however, which also has implications to your certificate.