(1 votes, average: 5.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

June 10, 2025 0

Chrome: New SSL Certificates Can’t Support Client Authentication Starting June 15, 2026

in Beyond Hashed Out, Hashing Out Cyber Security

Google’s Chrome Root Store Policy (v1.6) update encourages CAs not to wait to shift to PKI hierarchies that support server authentication only

Google Chrome has announced that it will stop trusting public server certificates (SSL/TLS certificates) that support the client authentication extended key usage (clientAuth EKU) starting June 15, 2026.

This change won’t impact most users or websites (e.g., organizations that use SSL certificates for server authentication only). But if you’re using your SSL certificate for client authentication, you’ll need to make changes sooner rather than later.

But why is this change happening? And what does this removal of the clientAuth EKU from public SSL certificates mean for your organization?

Let’s hash it out.

TL;DR: Key Takeaways You Need to Know

• The Chrome Root Program will stop accepting applications from PKI hierarchies using intermediate certificates that support mixed EKUs (i.e., clientAuth AND serverAuth). This change will take effect starting June 15, 2025.
• Any new public SSL/TLS certificates issued on or after June 15, 2026 must include ONLY the serverAuth EKU. Certificates issued prior to this date will remain valid until their expiration (unless revoked beforehand).
  • Public SSL/TLS certificates listing the clientAuth EKU will no longer be trusted.
  • To implement client authentication on public servers, you’ll need to use a separate client authentication certificate.

• Who will be impacted: Organizations that use SSL/TLS certificates for client authentication-related purposes will be impacted by the clientAuth EKU deprecation.
• These changes will have no effect on private CA client authentication certificates.

Timeline: When These Changes Will Occur

• Google recommends existing CAs move to new, dedicated PKI hierarchies before Sept. 15, 2025. This applies to CAs currently included in the Chrome Root Store that don’t yet support dedicated server authentication.
• Starting June 15, 2026: All publicly trusted SSL/TLS certificates must be issued by PKI hierarchies that support dedicated TLS server authentication. (Translation: no more mixed-use/multipurpose PKI hierarchies.)
• ClientAuth will no longer be included as an EKU in new leaf certificates issued by June 15, 2026. However, public CAs are rolling out the changes at different speeds ahead of the June deadline:
  • DigiCert stated it will no longer include the clientAuth EKU in public SSL/TLS certificates by default starting Oct. 1, 2025. The CA will completely eliminate the clientAuth EKU from all public SSL/TLS certificate issuances — including renewals, reissuances, and duplicate certificates — starting May 1, 2026.
  • Let’s Encrypt also announced a phased rollout that will end with the EKU being eliminated from certificates issued on or after May 13, 2026.
  • Sectigo has since announced its intention to stop issuing server certificates with that EKU by default with a phased rollout starting Sept. 15, 2025. It will then eliminate it from all certificates (no exceptions) by May 15, 2026.

Who Will These Changes Impact?

This change will not impact most websites, because the majority of SSL/TLS certificates are used for server authentication only.

However, the change will impact any businesses and other organizations that use server certificates for client authentication-related purposes (i.e., mutual TLS [mTLS] and server-to-server authentication). For example, it may impact some organizations in industries such as financial services and technology services.

However, this isn’t to say that only organizations in these industries will be impacted. It’ll also affect organizations within other sectors that use public server certificates for these client authentication-related purposes.

What Are Your Next Steps?

That answer depends on which side of the fence you’re on regarding SSL/TLS certificate uses.

• If you’re not using your SSL/TLS certificates for client authentication: You’re home free, you don’t have to do anything.
• If you’re one of the organizations using SSL/TLS certificates for client authentication: There are two alternative ways you can approach this.
  • Use a publicly trusted S/MIME certificate that includes the clientAuth EKU. Using a personal authentication certificate will allow you to authenticate specific individuals on your public-facing site.
  • Adopt private CA-based client authentication for internal use cases. You can take this approach instead if you want or need mutual TLS authentication to authenticate and secure other client-to-server and server-to-server connections.

Financial Services: In case you missed it, there’s a new dedicated PKI system in the works that’s designed with your industry’s specific needs in mind. Learn more about the X9 PKI system for the financial sector.

Background: Why All of This Is Happening in the First Place

For years, SSL/TLS certificates have been issued with two extended key usages, which define what a certificate can be used to authenticate:

• Server Authentication (ip-kp-serverAuth or object ID [OID] 1.3.6.1.5.5.7.3.1)
• Client Authentication (id-kp-clientAuth or OID 1.3.6.1.5.5.7.3.2)

In the CA/B Forum’s October 2024 meeting, Google’s representatives presented the Chrome Root Program’s updates, sharing (amongst other changes) its intention to eliminate clientAuth use cases from server SSL/TLS certificates for Chrome Root Program Policy, Version v1.6. This is part of a larger trend we’ve been seeing overall across the industry for a while now to move to dedicated PKI hierarchies.

The idea here is to eliminate multipurpose certificate trust chains in order to:

• improve the security of server certificates and, ideally,
• simplify their management.

Honestly, though, it’s best to separate those two extended key use cases to avoid eroding the public trust that’s intrinsic to PKI. So, just use SSL/TLS certificates to authenticate your public-facing server and have connecting clients use separate client authentication certificates. It’s really that simple.

Reminder: These changes to public SSL/TLS certificates have no impact on private PKI client authentication. This is because the changes affect only publicly trusted SSL/TLS certificates.

• #Client Authentication
• #SSL certificate
• #SSL/TLS Certificates