Extended Key Usage (EKU)

EKU contains a list of object identifiers (OIDs). The common ones are serverAuth (1.3.6.1.5.5.7.3.1) for TLS servers, clientAuth (1.3.6.1.5.5.7.3.2) for TLS clients, codeSigning (1.3.6.1.5.5.7.3.3), emailProtection (1.3.6.1.5.5.7.3.4) for S/MIME and timeStamping (1.3.6.1.5.5.7.3.8). While Key Usage limits cryptographic operations, EKU limits application purposes, and verifiers check that the purpose they need is listed.

Why it matters

EKU is now the main tool root programs use to separate PKI hierarchies by purpose. Under Chrome Root Program Policy v1.8, new subordinate CAs disclosed from 2026-06-15 must assert only serverAuth, and subscriber certificates issued on or after 2027-03-15 must assert only the serverAuth EKU. Let's Encrypt's classic profile stopped including clientAuth on 2026-02-11, and its tlsclient profile was discontinued on 2026-07-08. Anyone using public TLS certificates as client certificates for mTLS needs to move to a private CA or a dedicated client-authentication hierarchy.

Example

openssl x509 -in cert.pem -noout -ext extendedKeyUsage

A current public server certificate shows only TLS Web Server Authentication; an older one may also list TLS Web Client Authentication.

Common misconceptions

• Public TLS certificates will keep working for client authentication. The clientAuth EKU is being removed, and servers that check it will reject newer certificates.
• EKU is the same as Key Usage. They are separate extensions; a certificate must satisfy both when both are present.