Upcoming Mandatory Changes to Public Key Infrastructure (PKI)

Note:

Changes in Chrome Root Program Policy v1.7 are to be enforced after June 15, 2026. 

Affected & non-affected parties

Who is Affected?

Changes in Chrome Root Program Policy v1.7 directly impact organizations that use client authentication (or “dual-use”) certificates issued by public CA that are trusted by default in Chrome. These CA can no longer maintain a single root that issues both website SSL certificates and client ID certificates.
If your organization relies on publicly trusted certificates for mTLS (where the client certificate chains up to the same Public Root CA as the web server certificate) and the Public Root CA is in the Chrome Trusted Root List, you may be affected. You may no longer be able to purchase "dual-use" certificates (sometimes referred to as mTLS certificates) from these CAs after the deadline. Contact your vendor for details.

Who is NOT Affected?

• Private / Enterprise CAs: If you run an internal CA (a "locally trusted" CA) to issue client certificates to your employees for company sites’ access, you aren't affected. 

• Client Authentication Generally: Chrome is not removing support for client certificates. The browser still passes these certificates to the server for evaluation; it simply demands they do not originate from the same roots used for public website trust.

The change: mandatory Dedicated PKI Hierarchies by Chrome

The core change is a mandate for Dedicated TLS Server Authentication PKI Hierarchies. Chrome is enforcing a strict separation between certificates used to identify websites (Server Auth) and certificates used for other purposes, such as identifying clients/users (Client Auth).

1. The "Dual Use" Ban

Historically, a single Root CA could host sub-CAs that issued certificates for multiple purposes.  Under the new policy, any Root CA included in the Chrome Root Store must only be used for TLS Server Authentication.

• Subordinate CAs: Intermediate CAs chaining to a Chrome-trusted root must not allow for "Client Auth" or any extended key usage other than server TLS (`id-kp-serverAuth`).

• Subscriber (Leaf) Certificates: A single certificate can no longer be valid for both Server Authentication and Client Authentication. It must only assert the Extended Key Usage (EKU) of `id-kp-serverAuth`.

2. The June 15, 2026 Deadline (For Existing CAs)

Note: Chrome announced that they will allow CAs in their trust stores to issue certificates with Client Auth EKUs until March 2027. Chrome is still implementing many of their other policies on June 15, 2026, and we strongly recommend that you implement a strategy now to separate the certificates needed for client identity and server identity.

For CAs in the Chrome Root Store:

• Before June 15, 2026: Subordinate CAs are allowed to assert both Server and Client Auth EKUs (`id-kp-serverAuth` and `id-kp-clientAuth`)

• On or After June 15, 2026: All Subordinate CAs and Subscriber certificates must only assert `id-kp-serverAuth` 

• Consequence: If a hierarchy violates this after the deadline, Chrome will apply an "SCTNotAfter constraint," effectively distrusting any new certificates from that root issued more than 90 days after detection.

Why the change?

The primary driver is to create "purpose-driven PKIs" that are modern, simple, and secure.

• Scope Restriction: The Chrome Root Store is intended solely for TLS server authentication. Google explicitly states the store "is not used for any other PKI use case (e.g., TLS client authentication, secure email, code-signing, etc.)".

• Risk Reduction: By isolating the hierarchies trusted for websites, Chrome prevents security issues in other areas (like client identity or email) from impacting the trust of the public web ecosystem.

• Alignment: This move aligns all PKI hierarchies in the store on a single principle, allowing Chrome to phase out "multi-purpose" roots.

What affected parties need to do

For Salesforce customers who bring their own certificates to Salesforce Ecosystem 

1. Audit your mTLS usage: Check if your client or server certificates are issued by a Public CA that is also in the Chrome Root Store

2. Separate Trust Anchors: Ensure your architecture uses a Public CA for the Server identity (the website URL) and a different CA (Private or a non-Chrome-trusted Public root) for the Client identity

3. Prepare for Re-issuance: If you possess "dual-use" certificates issued by a Public CA, be aware that these may not be renewed in their current form after June 2026.

4. Reach out to your Public CAs to renew certificates from the new root hierarchy with separate use certificates. Some Public CA vendors are dropping the EKU before the deadline. The CA must be trusted by Salesforce, per this document, AND the client certificate must contain the client authentication EKU. Note, the document is about outbound calls, but the cacerts.jsp list is used for inbound mTLS as well.

Immediate Solution