Please concern the following setup: A client certificate is issued like this:

Root CA → Intermediate CA → Client Cert

Let's assume everything is fine up to here, the intermediate CA cert is properly signed by the root CA and the same for the client cert and the intermediate CA. The following files were produced:

  • root_ca.crt (containing only the root CA cert)
  • intermediate_ca.crt (containing only the intermediate CA cert signed by the root CA)
  • client.crt (containing only the client cert, signed by the intermediate CA)
  • client_key.pem (containing the private key belonging to the client cert)
  • ca_chain.pem, containing (in this order) the intermediate CA cert and root CA cert
  • client_ca_chain.pem, containing (in this order) the client cert, intermediate CA cert and root CA cert

Calling openssl x509 -in client.crt -noout -purpose gives:

Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
Time Stamp signing : No
Time Stamp signing CA : No

(I'm wondering a little about the CRL signing, Any Purpose and OCSP helper flags, but as I understood, they're OK and I can't get rid of them.)

Now, having configured an nginx server like this:

ssl_client_certificate /path/to/ca_chain.pem;
ssl_verify_client on;
ssl_verify_depth 2;

I will always get an error 400 and the following message when trying to access the site: client SSL certificate verify error: (26:unsupported certificate purpose) while reading client request headers.

(I can quickly reproduce this using curl --cert /path/to/client_ca_chain.pem --key /path/to/client_key.pem --cacert /path/to/ca_chain.pem -k https://${myUrl} or less quickly using a gui browser.)

I have spent some hours trying to figure out what the problem is here, but I can't and also searching the web for it didn't bring me further. So I would greatly appreciate any help!

  • 1
    It would be more helpful if you could actually provide the certificates in question. Then one could have a closer look at all of the certificates involved in the process of validation instead of getting only a summary of the leaf certificate. One could also try to reproduce the problem this way. Commented Aug 30, 2020 at 14:34
  • Does this answer your question? OpenVPN error=unsupported certificate purpose
    – mentallurg
    Commented Aug 30, 2020 at 15:29
  • @SteffenUllrich, agreed, this might be more helpful. After creating a new "throw-away" certificate chain (without my personal stuff, OCSP, CRL, etc.) to publish here I found everything working with these certificates. In the next days, I will dig deeper into this in order to find the crucial difference and get back on this. Many thanks for the moment!
    – ahuemmer
    Commented Aug 30, 2020 at 16:02
  • @mentallurg, thank you, but this doesn't seem to fit to my problem.
    – ahuemmer
    Commented Aug 30, 2020 at 16:02
  • @ahuemmer: "After creating a new "throw-away" certificate chain ... I found everything working with these certificates." - that's what I kind of expected, i.e. that the problem is in something not shown in the question. Commented Aug 30, 2020 at 16:40

1 Answer 1


Indeed, as suggested, it is necessary to have a close look not only at the client certificate, but also at the other certs in the chain. In my case, it turned out, the the root cert was generated with a config entry like

extendedKeyUsage = serverAuth

This will result in the root CA having the purpose flags

SSL client : No
SSL client CA : No

(I think the second of which is the crucial one). So, when traversing the cert chain "upwards", nginx (or any other correctly working software) will find out, that the root CA itself was never "allowed" to sign client certs. At this time, it's not relevant, what the intermediate CA is "allowed" to do (in my case, both the flags were Yes indeed).

The solution is to completely omit the extendedKeyUsage line when creating your root CA, which will result a wide-purpose certificate. (This is even the suggested way! 1,2) If necessary, you could narrow down the purposes using extendedKeyUsage when creating the intermediate CA.

Anyway, in my case, it would also have been sufficient to use extendedKeyUsage = serverAuth,clientAuth for the root CA. But as stated, this is not the advised way to go.

You must log in to answer this question.

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