Client Authentication EKU in TLS Certificates: mTLS, Policy Changes, Impact, and Alternatives

Two important EKU values are:

• Server Authentication (serverAuth): Allows a certificate to authenticate a server, for example, during an HTTPS connection.
• Client Authentication (clientAuth): Allows a certificate to authenticate a client, such as a user, device, or application connecting to a server.

Certificate Authorities (CAs) are phasing out the Client Authentication Extended Key Usage, which has traditionally allowed certificates to authenticate both servers and clients and are moving toward a single purpose - Server Authentication.

This change mainly affects organizations using certificates for mutual TLS (mTLS), API authentication, and server-to-server communication. Standard HTTPS websites are not affected.

What Is Changing and When?

The transition is happening in stages, and DigiCert and Sectigo have different final issuance dates.

For now, all Sectigo, Thawte, RapidSSL, GeoTrust, DigiCert DV, OV and EV and GoGetSSL OV and EV TLS products, obtained via GoGetSSL include Client Authentication EKU by default. After the deadlines, it will no longer be available in public TLS certificate issuance.

Note: The same products obtained via different provider may not include clientAuth by default. Please clarify the information before placing the order.

Existing certificates containing clientAuth are not automatically revoked by this change. They can remain valid until expiration or revocation, subject to applicable trust-store and application policies.

What Is mTLS and Why Does It Need Client Authentication?

Mutual TLS (mTLS) is an extension of the standard TLS authentication process. In regular HTTPS, the server presents its certificate to authenticate itself to the client. With mTLS, both sides present certificates and authenticate each other.

For example, when an application connects to an API using mTLS:

1. The API server presents its server certificate.
2. The client verifies the server's identity.
3. The client presents its own certificate containing the Client Authentication EKU.
4. The server verifies the client's identity.
5. Once both sides are authenticated, the encrypted connection is established.

This approach is commonly used for:

• API-to-API communication
• Server-to-server authentication
• Financial services and payment systems
• Device and machine authentication
• Secure connections between business partners

If your infrastructure relies on clientAuth in public TLS certificates, you need to plan an alternative before the applicable CA deadline.

Who Is Affected?

Usually not affected:

• Website owners using certificates only for HTTPS.
• eCommerce websites and standard business websites.
• Applications that use TLS only to authenticate servers.

Should review their certificate setup:

• Organizations using mTLS.
• Companies relying on certificate-based API authentication.
• Businesses using certificates for machine or device identity.
• Systems using public TLS certificates for server-to-server authentication.

If you are unsure whether your certificates are used for client authentication, inspect their EKU extensions and review the TLS configuration of your applications.

What Are the Alternatives to Public TLS Certificates for Client Authentication?

Organizations that require clientAuth can consider several alternatives.

1. X9 PKI for TLS

DigiCert X9 PKI for TLS, available through GoGetSSL, is designed for non-browser TLS connections, including mTLS, secure APIs, financial systems, and host-to-host communication between organizations.

Unlike standard browser-trusted TLS certificates, X9 certificates are issued under an independent PKI framework developed with the ASC X9 financial standards organization. They use a common trust framework that allows participating organizations to authenticate each other.

X9 certificates support both Server Authentication and Client Authentication EKUs, allowing them to authenticate servers, clients, or both. An optional Key Encipherment / Key Agreement feature is also available to support additional key exchange methods, such as RSA key exchange and Diffie–Hellman, when required by your server or application. Digital Signature is included by default.

When should you use X9 PKI?

• For external mTLS: An organization can use a standard public TLS certificate for its browser-facing website or API server and an X9 certificate for client authentication. The receiving server must trust the X9 certificate chain.
• For host-to-host connections between organizations: Both parties can use X9 certificates for server and client authentication, provided both systems trust the X9 PKI hierarchy.
• For internal systems: X9 can also be used if the relevant systems trust its certificate chain. However, for environments that are strictly internal and do not require interoperability with external organizations, a Private PKI may be a more appropriate choice.

Learn more: DigiCert X9 PKI for TLS from GoGetSSL.

2. Private PKI

A private Certificate Authority allows an organization to issue and manage its own client authentication certificates.

It is particularly suitable for internal systems, employee devices, applications, and services operating within a controlled trust environment.

Learn more: PKI Solutions.

3. S/MIME Certificates

Some S/MIME certificate products continue to support client authentication EKU. They may be suitable for certain certificate-based authentication scenarios, depending on the application's requirements and compatibility.

However, S/MIME certificates should not be treated as a universal replacement for TLS client certificates. Check the intended use and supported trust model before choosing this option.

Learn more: S/MIME Certificates.

What Should You Do Before the Deadline?

If your organization uses public TLS certificates for client authentication, take these steps:

1. Audit your certificates: Check whether they contain the clientAuth EKU.
2. Review mTLS configurations: Identify applications, APIs, devices, and services that rely on client certificates.
3. Check renewal dates: Remember that renewals and reissues after the CA's final deadline will also be affected.
4. Choose an alternative: Evaluate X9 PKI or Private PKI based on whether your connections involve external partners or internal systems.
5. Test the migration: Verify certificate trust, client authentication, and application compatibility before replacing existing certificates.

Do not wait until the final issuance deadline. Plan the migration early enough to test all dependent systems.

Frequently Asked Questions

Will my existing certificate stop working after the deadline?

Certificates issued with clientAuth before the applicable deadline can remain valid until expiration or revocation.

Will this change affect my website's HTTPS connection?

No. Standard HTTPS uses Server Authentication EKU. Websites that use certificates only for server authentication are not affected.

Can I still order a public TLS certificate with Client Authentication EKU?

Currently, all Sectigo, Thawte, RapidSSL, GeoTrust, DigiCert DV, OV and EV and GoGetSSL OV and EV TLS products, obtained via GoGetSSL include Client Authentication EKU by default. Please note, CAs will start deprecation before the announced deadline.

Can I order a public SSL/TLS certificate for mTLS after the change?

Public TLS certificates issued after the applicable deadline will no longer include Client Authentication EKU. For mTLS, consider X9 PKI for TLS or a Private PKI solution.

Is X9 PKI for TLS suitable for regular websites?

No. X9 PKI is designed for non-browser TLS and client authentication use cases. Standard browser-facing websites should continue using publicly trusted SSL/TLS certificates.

Does this change affect S/MIME certificates?

The announced restrictions concern public TLS certificate issuance. S/MIME products may continue to support client authentication, depending on their certificate profiles and intended use.