Sectigo and DigiCert to Remove Client Authentication EKU from Public SSL/TLS Certificates

In response to evolving browser policies and heightened security requirements, Sectigo and DigiCert both announced they will remove the Client Authentication Extended Key Usage (EKU) from public SSL/TLS certificates.

It is part of a broader initiative to support Google Chrome’s Root Program and CA/Browser Forum best practices. It directs public certificates to server authentication (HTTPS) only, with client authentication to private or special PKI systems.

What is Changing?

Sectigo Timeline:

• New public SSL/TLS certificates that are issued on September 15, 2025, will not, by default, have the Client Authentication EKU.
• May 15, 2026: The Client Authentication EKU will no longer be allowed in any public SSL/TLS certificate, period.

DigiCert Timeline:

• October 1, 2025: DigiCert will not automatically include the Client Authentication EKU in public TLS certificates anymore. Clients can still request it manually during registration.
• Starting May 1, 2026, DigiCert will no longer allow the Client Authentication EKU to be added to all public TLS certificate types, including renewals, reissues, and duplicates.
• As of June 15, 2026, Google Chrome will only support public TLS certificates issued by special TLS root authorities (such as DigiCert Global G2, G3, TLS ECC P384 Root G5, etc.).

It is important to note, the deprecation of the Client Authentication EKU will not impact the existing public SSL/TLS Certificates issued before these dates. These public SSL/TLS Certificates will remain valid until they expire or have been revoked.

Why is this Happening?

Leading certificate authorities like Sectigo and DigiCert have stopped adding the Client Authentication Extended Key Usage (EKU) to public SSL/TLS certificates because of stricter guidelines from browsers, mainly Google Chrome’s Root Program.

The change is meant to make security better by ensuring public certificates are not misused for anything other than server authentication, mainly to secure sites using HTTPS.

Having one certificate perform both client and server authentication has the potential to be hazardous, including abuse, confusion about what the certificate is utilized for, and weaker security between public and private PKI infrastructures.

By removing the Client Authentication EKU, certificate authorities are following best practices from the CA/Browser Forum to allow better security and interoperability.

While using one certificate configuration for both server and client authentications may appear beneficial, it can be problematic in several ways, such as:

• Unintentional misuse of the certificate
• Less visibility into the intent of use
• Risk of having compromised security boundaries between public and private PKI infrastructures

By removing the Client Authentication EKU, CAs, and the broader industry are reinforcing the clear distinction between public and private use cases for certificates.

Who Is Affected?

Organizations employing public SSL/TLS certificates for server-to-server authentication, client or device authentication, or mutual TLS (mTLS) are affected by this change.

If your systems employ certificates that have the Client Authentication EKU, you must take action before the deadlines listed in 2026.

If all you ever do with SSL/TLS certificates is utilize them for HTTPS, like making your website secure, this change does not apply to you.

Existing certificates that have the Client Authentication EKU remain valid until they reach their expiration date, but new certificates and renewals will not have that usage extension after the deadlines.

In short, if you’re using SSL certificates just to secure websites, no changes are required. But if you’re leveraging these certificates for client-side authentication, immediate planning is necessary.

What Should Organizations Do?

Organizations that depend on public SSL/TLS certificates for client authentication must start making plans to migrate to a private PKI or some other trusted environment.

The process starts by auditing all existing certificates and determining which ones are utilized for mTLS or other client-side authentication.

If client authentication remains necessary beyond 2026, organizations must make plans to migrate to Private PKI solutions or DigiCert’s X9 PKI, which accommodates server and client EKUs and is compatible with regulatory requirements.

Preplanning will keep things humming, prevent problems, and ensure compliance with changing browser and security regulations. Both Sectigo and DigiCert provide consultation services to aid in the transition.

Unlike publicly trusted certificates, Private CAs (Certificate Authorities) offer:

• Full control over certificate issuance
• Support for custom EKUs, including client authentication
• Flexible mTLS and device authentication capabilities

Here’s what you should do next:

1. Audit your current SSL/TLS certificate usage.
2. Identify any use cases involving client authentication.
3. Plan your migration to Private PKI well in advance of the May 15, 2026 deadline.

How Certera Can Help?

Certera is proactively supporting affected organizations with end-to-end PKI solutions. These offerings are designed to meet enterprise needs such as Certificate Lifecycle Management, Private CA, Managed PKI, Enterprise S/MIME, and more.

Additionally, we provide consultation services to help you:

• Assess your current certificate deployments
• Design a tailored PKI migration plan
• Implement and manage a secure private CA environment

Conclusion

Sectigo will remove the Client Authentication EKU from publicly trusted SSL/TLS certificates on May 15, 2026. DigiCert will also remove it on May 1, 2026. This is an important change in digital certificate usage. It keeps public and private PKI usage isolated.

This will minimize risks and provide compliance with what browsers demand. Organizations employing certificates for non-HTTPS purposes need to move now—transition to Private PKI or secure alternatives such as DigiCert’s X9 PKI to keep safe and uninterrupted authentication processes.

If you do this sooner rather than later, you will be positioned for ongoing security, compliance, and operational reliability.