Last updated: August 21, 2023
Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates bind a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.
As part of establishing a secure connection to a website, Chrome verifies that a recognized system known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.
Root stores, sometimes called “trust stores,” tell operating systems and applications what certificates to trust. The Chrome Root Store contains the set of certificates Chrome trusts by default.
Historically, Chrome integrated certificate verification processes with the platform it ran on. This resulted in inconsistent user experiences across platforms, making it difficult for developers to understand Chrome's expected behavior.
The Chrome Certificate Verifier addresses these concerns by applying a common certificate verification process across Windows, macOS, Chrome OS, Linux, and Android. Apple policies prevent the Chrome Certificate Verifier and corresponding Chrome Root Store from being used on Chrome for iOS.
We expect the transition to the Chrome Root Store and Chrome Certificate Verifier to be seamless for most users.
As the transition occurs, a small population of users may notice that a small number of websites that successfully loaded in earlier versions of Chrome now present a “Your connection is not private” warning. When a website’s certificate does not validate to a certificate included in the Chrome Root Store or a user’s local settings, users will see detailed error language that includes “ERR_CERT_AUTHORITY_INVALID.”
See the troubleshooting steps here.
We expect the transition to the Chrome Root Store and Chrome Certificate Verifier to be seamless for most website operators.
We encourage website operators to configure HTTPS for their site(s) with certificates that follow modern best practices, including those found in the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and the Chrome Root Program policy.
If your website’s certificate issuer is not included in the Chrome Root Store, consider transitioning to another service provider to avoid compatibility issues.
We expect the transition to the Chrome Root Store and Chrome Certificate Verifier to be seamless for Enterprise CA owners.
Enterprise CAs are intended for use cases exclusively internal to an organization (e.g., a TLS certificate issued to a corporate intranet site).
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. Consequently, if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. Consequently, if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
The Chrome Certificate Verifier evaluates certificate profile conformance against RFC 5280, and in some cases, is more strict than platform verifiers. As a result, an enterprise policy will temporarily be available to re-enable the platform root store and certificate verifier to provide enterprises time to remediate certificate profile conformance errors. See more below.
CA Owners who meet the Chrome Root Program policy requirements may apply for a CA certificate’s inclusion in the Chrome Root Store. CAs included in the Chrome Root Store are expected to adhere to the Chrome Root Program policy and continue to operate in a consistent and trustworthy manner. A CA owner’s failure to follow the requirements defined in the Chrome Root Program policy may result in a CA certificate’s removal from the Chrome Root Store, limitations on Chrome's acceptance of the certificates they issue, or other technical or policy restrictions.
A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues.
The table below shows the rollout of these new features across platforms.
Chrome on...* | Chrome Root Store Rollout Begins** | Chrome Root Store Enabled by Default | Sunset of Enterprise Policy*** |
---|---|---|---|
Android | Chrome 114 | Chrome 115 | Chrome 120 |
Chrome OS | Chrome 114 | Chrome 114 | Chrome 119 |
iOS**** | N/A | N/A | N/A |
Linux | Chrome 114 | Chrome 114 | Chrome 119 |
macOS | Chrome 105 | Chrome 108 | Chrome 112 |
Windows | Chrome 105 | Chrome 108 | Chrome 112 |
Notes:
(*) Find Chrome browser system requirements here.
(**) During this release, users also had the opportunity to “opt-in” to these features, regardless of whether they were automatically enrolled in the rollout population.
(***) The ChromeRootStoreEnabled enterprise policy will be temporarily available to revert to the platform root store and verifier. The version represented in this column is the last version of Chrome where the corresponding platform will support the enterprise policy.
(****) Apple policies prevent the Chrome Root Store and Chrome Certificate Verifier from being used on Chrome for iOS.
As the transition to the Chrome Root Store and Certificate Verifier occurs, a small population of users may notice that a small number of websites that successfully loaded in earlier versions of Chrome now present a “Your connection is not private” warning that includes a message that reads “NET::ERR_CERT_AUTHORITY_INVALID.”
Troubleshooting (for developers, system administrators, or “power users”):
Verify the Chrome Root Store and Certificate Verifier are in use.
Choose to either add the website’s corresponding root CA certificate to your platform root store or temporarily use a Chrome Enterprise Policy to disable the Chrome Root Store and Certificate Verifier.
Add a CA certificate to the platform root store: Refer to your operating system instructions for managing certificates.
Warning: You should never install a root certificate without carefully considering the impact this might have on your privacy and security. Only install a root certificate after obtaining it from a trusted source and verifying its authenticity (e.g., verifying its SHA-256 thumbprint).
Use the Chrome Enterprise Policy: See below.
If you believe the Chrome Certificate Verifier is not working as intended, submit a bug and attach a NetLog dump repeating the steps leading to the issue from a new Incognito window. Add a comment to route the bug to the Internals>Network>Certificate component for the fastest routing to the appropriate triage team.
If you believe you've identified a Security Bug, follow these instructions.
The Chrome Certificate Verifier evaluates certificate profile conformance against RFC 5280, and in some cases, is more strict than platform verifiers. The ChromeRootStoreEnabled enterprise policy will be temporarily available to revert to the platform root store and verifier.
This enterprise policy will be available for a limited time only and should only be used as a temporary solution while troubleshooting and remediating instances of certificate profile conformance issues.
Chrome uses a “component updater” tool to push specific updates to browser components without updating the Chrome browser application. As root CA certificates are added or removed from the Chrome Root Store, the component updater will automatically propagate these changes to user endpoints without user action.
If your enterprise has disabled component updates, endpoints will only receive updated versions of the Chrome Root Store during Chrome browser application updates.
During routine operating conditions, the Chrome Root Store is updated approximately quarterly. However, aperiodic updates may take place to promote the safety and privacy of Chrome's users.
On Windows, the Chrome Certificate Verifier will automatically consume certificates added to the following certificate stores:
Local Machine (accessed via certlm.msc)
Current User (accessed via certmgr.msc)
On macOS, the Chrome Certificate Verifier will automatically consume certificates added to the following certificate stores:
Trust:
Distrust:
Historically, Chrome has integrated with platform certificate stores to support the use of client authentication certificates. This behavior is unchanged by the rollout of the Chrome Root Store and the Chrome Certificate Verifier.
See these testing instructions.
The most recent version of the Chrome Root Store is available here.
The Chrome Root Store is updated by Component Updater. To observe the contents of the Chrome Root Store in use by a version of Chrome where it has been launched:
chrome://system
Expand
... button next to chrome_root_store
The Chrome Certificate Verifier will apply standard processing to include checking:
Chrome applies additional processing rules for certificates chaining to roots included in the Chrome Root Store, such as:
The Chrome Certificate Verifier was designed to follow path-building guidance established in RFC 4158.
Source locations include //net/data/ssl/chrome_root_store, //net/cert, //services/cert_verifier, and //chrome/browser/component_updater/.
Source locations include //net/cert, //net/cert/internal, and //net/cert/pki.