What does "unsupported certificate purpose" mean?

The certificate's extended key usage does not permit the use being attempted. A certificate with only serverAuth used as a client certificate produces it, and so does a CA certificate lacking keyCertSign in its key usage.

Can a certificate have both serverAuth and clientAuth?

Yes, and it is common for service-to-service traffic where each side both calls and is called. Public CAs routinely issue certificates carrying both.

What happens if a certificate has no EKU at all?

Most implementations treat an absent extended key usage as "no restriction" and allow any purpose. Present but not listing what you need is a hard failure — so absent and empty behave very differently.

Why is keyUsage marked critical?

Critical means an implementation that does not understand the extension must reject the certificate rather than ignore it. For a constraint whose whole job is to restrict use, being silently skipped would defeat the point.

Key usage and extended key usage

Key Usage restricts what the *key* may do at a cryptographic level — sign, encipher, sign certificates — while Extended Key Usage restricts what the *certificate* may be used for at an application level, such as TLS server authentication or client authentication. Both are enforced. A certificate must carry `serverAuth` in its extended key usage to terminate TLS and `clientAuth` to be used for mutual TLS; missing either produces an "unsupported certificate purpose" error that does not name the extension responsible.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

The difference in one line #

Key Usage — what the key is allowed to do. Cryptographic operations.
Extended Key Usage — what the certificate is allowed to be used for. Application purposes.

openssl x509 -in certificate.crt -noout -ext keyUsage -ext extendedKeyUsage

Expected output

X509v3 Key Usage: critical
  Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
  TLS Web Server Authentication, TLS Web Client Authentication

Key Usage values #

Value	Meaning
`digitalSignature`	Sign data. Needed for most TLS key exchanges
`keyEncipherment`	Encrypt a key. Needed for RSA key transport
`keyAgreement`	Participate in a key agreement, e.g. ECDH
`dataEncipherment`	Encrypt data directly. Rarely used
`keyCertSign`	Sign other certificates. CA certificates only
`cRLSign`	Sign certificate revocation lists. CA certificates only
`nonRepudiation`	Non-repudiable signatures

keyCertSign is the one that matters most: a CA certificate without it cannot sign, and an end-entity certificate with it is a serious misissuance.

Extended Key Usage values #

Value	Used for
`serverAuth`	Terminating TLS as a server
`clientAuth`	Presenting a client certificate in mutual TLS
`codeSigning`	Signing executables
`emailProtection`	S/MIME
`timeStamping`	Timestamping authorities
`OCSPSigning`	Signing OCSP responses

What each certificate type needs #

A TLS server certificate

basicConstraints = critical,CA:FALSE
keyUsage         = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth

An mTLS client certificate

basicConstraints = critical,CA:FALSE
keyUsage         = critical,digitalSignature,keyEncipherment
extendedKeyUsage = clientAuth

A CA certificate

basicConstraints = critical,CA:TRUE
keyUsage         = critical,digitalSignature,keyCertSign,cRLSign

Note what is absent from the CA example: no extended key usage. A CA that restricts its EKU constrains every certificate beneath it, which is occasionally what you want and usually a source of confusing failures.

Diagnosing “unsupported certificate purpose” #

What does OpenSSL think this certificate is for?

openssl x509 -in certificate.crt -noout -purpose

Expected output

Certificate purposes:
SSL client : Yes
SSL server : Yes
Any Purpose : Yes
CRL signing : No

That table is derived from both extensions together, so it answers the question directly rather than leaving you to reason about which restriction bit.

Where these get lost #

Signing a CSR with openssl x509 -req drops every extension from the request unless you pass -copy_extensions or supply your own with -extfile. A certificate issued without either has no key usage and no extended key usage at all — which, per the note above, often works, right up until it meets an implementation that requires serverAuth explicitly.

See signing a CSR with your CA.

Frequently asked questions

What does "unsupported certificate purpose" mean?: The certificate's extended key usage does not permit the use being attempted. A certificate with only serverAuth used as a client certificate produces it, and so does a CA certificate lacking keyCertSign in its key usage.
Can a certificate have both serverAuth and clientAuth?: Yes, and it is common for service-to-service traffic where each side both calls and is called. Public CAs routinely issue certificates carrying both.
What happens if a certificate has no EKU at all?: Most implementations treat an absent extended key usage as "no restriction" and allow any purpose. Present but not listing what you need is a hard failure — so absent and empty behave very differently.
Why is keyUsage marked critical?: Critical means an implementation that does not understand the extension must reject the certificate rather than ignore it. For a constraint whose whole job is to restrict use, being silently skipped would defeat the point.

References

RFC 5280: X.509 and CRL profile — the specification every field on a certificate comes from