Salesforce PKI Mandatory Changes: Chrome Root Program Policy 2027

This article explains what Chrome Root Program Policy v1.8 requires, who is affected, and what Salesforce customers must do before the March 15, 2027 enforcement deadline. It answers questions such as: "Will my mTLS certificates stop working in Chrome?" and "Do I need to change my certificate setup for Salesforce?"

Public Key Infrastructure (PKI) is the system of certificates and certificate authorities (CAs) that establishes trust for encrypted connections. A CA is an organization that issues digital certificates. Chrome's Root Store is the list of CAs that Google Chrome trusts by default for website (TLS server) authentication.

The core change in Chrome Root Program Policy v1.8 mandates that any CA in the Chrome Root Store may only issue certificates for TLS Server Authentication — not for client authentication or any other purpose. This separation affects organizations that currently use "dual-use" certificates (also called mTLS certificates) issued by a publicly trusted CA that appears in the Chrome Root Store.

Note: Changes in Chrome Root Program Policy v1.8 are to be enforced after March 15, 2027 (moved from June 15, 2026). 

Affected & non-affected parties

Who is Affected?

Changes in Chrome Root Program Policy v1.8 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 March 15, 2027 Deadline (For Existing CAs)

For CAs in the Chrome Root Store:

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

• On or After March 15, 2027: 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.