Having set up a new OpenVPN system, I suddenly struggled with the following error message in my syslog:<\/p>\n
VERIFY ERROR: depth=0, error=unsupported certificate purpose: \/C=....\n<\/pre>\n
\nAt 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<\/a>“, section “Certificate doesn\u2019t 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 statementtls-verify<\/code>. However, I did not make use of it.
\nAfter a long search, the Linode Forum Thread “OpenVPN help… verify error depth=0?<\/a>” 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<\/em> set to server<\/em>:<\/p>\n[...]\nnsCertType = server\nsubjectKeyIdentifier=hash\nauthorityKeyIdentifier=keyid,issuer:always\nextendedKeyUsage=serverAuth\nkeyUsage = digitalSignature, keyEncipherment\n<\/pre>\nAs 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:<\/p>\n
\n
- Use nsCertType=server<\/em> certificates only for your OpenVPN server!<\/li>\n
- Do not use nsCertType=server<\/em> certificates for your OpenVPN clients!<\/li>\n<\/ul>\n
If you obey these rules, you will not have a problem with the error message on an “Unsupported Certificate Purpose” at server side.<\/p>\n
Edit on 2020-08-08:<\/h3>\n