Key Takeaways
- EKU scope is narrowly defined for purposes beyond the Basic Key Usage.
- Public CAs proactively depreciate Client Authentication EKU in TLS certificates.
- Organizations have to distinguish between server and client certificates.
- Proper inventory and profiling avoid service interruption.
- Schedules from Sectigo and DigiCert require urgent action before the next renewal period.
EKU is an essential X.509 certificate extension used to define what cryptographic purposes can be fulfilled with the public key of a certificate. Recent updates from the CA regarding the Client Authentication EKU redefine practices in the sphere of public key infrastructure. These changes necessitate adjustments to organisations’ certificate policies.
What Does Extended Key Usage Mean in Certificates?
Extended Key Usage is a kind of X.509 certificate extension that specifies particular purposes of the public key of a certificate. The difference between this extension and the Key Usage field consists in the fact that the latter includes only general uses such as digital signatures or key encryption.
EKU limits the use of certificates to specific purposes such as server authentication, client authentication, code signing, email protection, etc. This field is checked by applications and systems before using the certificate. When the purpose is not found, the certificate is rejected.
Thus, separation of certificate uses prevents the reuse of one certificate for various purposes.
What Is the Structure of the EKU Certificate Extension?
The structure of the EKU extension is quite simple and is described by the ASN.1 syntax in accordance with RFC 5280. The object identifier of this extension is 2.5.29.37.
Its value is presented in the form of a SEQUENCE of one or more KeyPurposeId objects, which are OBJECT IDENTIFIERS denoting an allowed purpose of use.
Common OIDs include:
- 1.3.6.1.5.5.7.3.1 (serverAuth)
- 1.3.6.1.5.5.7.3.2 (clientAuth)
- 1.3.6.1.5.5.7.3.3 (codeSigning)
- 1.3.6.1.5.5.7.3 (emailProtection)
Why Is EKU Playing an Undercover Game in X.509 Certificates?
Key Usage only covers fundamental crypto functionalities, like signing and key encryption of keys. EKU provides a second, more stringent level of check, implemented by applications.
In spite of a proper Key Usage value, an attempt to validate the certificate will fail if the required EKU is not present. A TLS server certificate lacking the serverAuth OID cannot be used for an HTTPS connection.
The same certificate cannot be used for authentication as a client in mTLS without clientAuth. It cannot be used for S/MIME encryption by email clients without emailProtection. Also, it cannot sign code without code signing.
How is EKU Different from the Key Usage Extension?
Key Usage and Extended Key Usage collaborate, but have their own level of control. Key Usage controls the cryptographic usage of the key. EKU selects which practical purposes can employ that key.
| Aspect | Key Usage | Extended Key Usage |
| Purpose | Defines basic cryptographic operations | Defines high-level application purposes |
| Granularity | Coarse (digitalSignature, keyEncipherment, etc.) | Fine-grained (serverAuth, clientAuth, codeSigning, etc.) |
| Enforcement | Cryptographic engines | Applications and relying parties |
| Criticality | Cryptographic engines | Frequently marked critical for security |
- Designers of certificates have to add both extensions; only one is not enough.
- Validators first check Key Usage for cryptographic capability, followed by EKU for application capability.
- Absence of a correct EKU will invalidate the certificate despite a seemingly flawless Key Usage extension.
What is Client Authentication EKU?
Client Authentication EKU has the object identifier 1.3.6.1.5.5.7.3.2. The presence of that OID indicates that the certificate is used to verify the identity of the client to the server.
If the certificate contains that extension, the holder can use it to authenticate itself as a TLS client. That requirement is enforced by the servers during the mutual TLS handshake process. When verifying the certificate, the server checks the signature path along with the clientAuth EKU.
The lack of this extension means that even an otherwise cryptographically valid certificate will not pass the client authentication procedure. Such certificates are simply ignored by the applications.
What is the Difference Between Server Authentication And Client Authentication EKU?
Server Authentication and Client Authentication EKUs work on opposing ends of a TLS link. They differ in OIDs and directions of trust.
Server Authentication (1.3.6.1.5.5.7.3.1)
- Use cases: Secure websites (HTTPS), APIs, load balancing services
- Trust direction: Clients authenticate the server’s identity
- Validation: Browsers and other clients will not accept the certificate without the OID in their encrypted session
Client Authentication (1.3.6.1.5.5.7.3.2)
- Use cases: Mutual TLS, identifying services, establishing connections between devices or clients, VPN connections
- Trust direction: Server authenticates the client’s identity
- Validation: This OID is needed by the servers in the process of a TLS handshake; otherwise, the connection won’t start
Even though a certificate can contain both of them at once, nowadays, public CAs separate these purposes.
Why Is Client Authentication EKU Changing?
There are several well-defined reasons why public certificate authorities are stripping the Client Authentication EKU out of TLS certificates.
First, stronger baseline standards from the CA/Browser Forum and Chrome Root Program mandate purpose separation. TLS certificates issued publicly may only have the serverAuth EKU.
Second, there is increased exposure through dual-purpose certificates. A certificate that does both client and server authentication introduces additional risk when compromised.
Third, current best practices in PKI suggest least privilege. Client authentication should occur in private/enterprise PKIs where organisations manage issuance, validity, and revocation.
What Does the Deprecation of the Client Authentication EKU Mean?
The leading certificate authorities have stopped including the Client Authentication EKU in publicly available TLS certificates. CA/B Forum and the Chrome Root Program mandate that publicly trusted server certificates should only have the serverAuth key usage purpose.
As per the new policies, DigiCert, Sectigo, Let’s Encrypt, among others, no longer include the clientAuth OID by default. Almost all certificate providers have disabled the possibility of issuing such certificates.
Dual-purpose certificates will continue working till their expiry, but any renewed or newly issued certificate will not include the clientAuth EKU.
This policy will force companies using public certificates for mutual TLS to migrate client authentication to private PKI infrastructure.
What Are the Effects of EKU Deprecation for Client Authentication?
The absence of Client Authentication EKU from public TLS certificates causes an immediate impact on business.
The most vulnerable to this change are mutual-TLS implementations. The certificates that used to have both serverAuth and clientAuth capabilities will function fine until they expire. When renewed, the new certificate no longer has the clientAuth capability, resulting in a handshake failure.
Any system that utilizes a public TLS certificate as a client identity will go out of work upon the renewal period. Companies will find out about the issue by experiencing traffic failure if they do not prepare the inventory of dual-EKU applications ahead of time.
What Are the EKU Deprecation Timelines for Sectigo and DigiCert?
Each of these organisations uses a two-phase process. Check your certificates against the following dates.
DigiCert
- 1 October 2025: Will stop using clientAuth by default
- 1 March 2027: Will completely remove clientAuth from new certificates, reissuances, and renewals
Sectigo
- 14 October 2025: Will stop using clientAuth by default
- 10 February 2027: Will completely remove clientAuth from all new SSL/TLS certificates
Dual-EKU certificates stay valid until their expiration. Renewed certificates will no longer include the clientAuth purpose.
How can Organisations Plan for EKU Client Authentication Changes?
Organisations need to take steps well ahead of the next renewal cycle. Do the following to stay away from service outages:
- List down all certificates that have a clientAuth EKU right now. Employ tools like OpenSSL or even certificate management utilities to conduct inventories of your production and staging environments.
- Classify your server and client certificate profiles. Create individualised client certificates using your private Certificate Authority for all your mutual TLS and device identity use cases.
- Revamp automation and ACME workflows. Exclude requests that are still trying to acquire dual-EKU certificates from public CAs.
- Test your mutual TLS communication under the new conditions. Swap your dual-EKU certificates with those of just clientAuth in non-production environments to see if handshakes complete successfully.
- Contact certificate authorities. Make sure you know their exact cut-off date and learn about the solutions they offer for client authentication or even private PKI solutions.
Common FAQs
Is it possible for a certificate to still have serverAuth and clientAuth at once?
The issuance of dual-EKU certificates by public CAs has been discontinued. Current ones continue to have both until expiration.
What about existing certificates after the deprecation date?
They are going to be operational and valid until their expiration. They won’t be revoked automatically.
Are there any restrictions on private CAs?
No. Unlike public CAs, private/enterprise CAs don’t have to comply with the CA/Browser Forum public-trust requirements.
How does the implementation happen via browser or OS vendors?
Chrome and other root programs will stop accepting new public certificates with clientAuth after the enforcement dates.
Conclusion
Being aware of Extended Key Usage and responding to the deprecation will improve the position of every PKI-enabled company. These changes will lead to improved role separation, tighter purpose controls, and proper certificate lifecycle management practices.
This new development should be considered an opportunity rather than a requirement. Identify dual-purposed certificates, move client authentication into internal PKI, and update your certificate profiles immediately.
