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

Source: https://certguru.io/concepts/key-usage-vs-eku/
Last updated: 2026-08-19
Commands 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.

```bash
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*

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

*An mTLS client certificate*

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

*A CA certificate*

```ini
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?*

```bash
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.

> **Absent and empty are different**
>
> A certificate with **no** extended key usage extension is generally accepted for any purpose. A
>   certificate **with** one that does not list what you need is rejected. So adding an EKU can break
>   something that previously worked — which is why an over-restrictive CA template causes such
>   puzzling failures.

## 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](/openssl/sign-csr-with-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](https://www.rfc-editor.org/rfc/rfc5280) — the specification every field on a certificate comes from

## Related pages

- https://certguru.io/concepts/mtls/
- https://certguru.io/openssl/sign-csr-with-ca/
- https://certguru.io/openssl/create-mtls-client-certificate/
- https://certguru.io/openssl/view-certificate/
- https://certguru.io/openssl/create-root-ca/

--
CertGuru — https://certguru.io