the Chromium logo

The Chromium Projects

Chrome Root Program Policy, Version 1.5

Last updated: 2024-01-16

Bookmark this page as https://g.co/chrome/root-policy

Table of Contents

Introduction

Google Chrome relies on Certification Authority systems (herein referred to as “CAs”) to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website’s certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.

When making HTTPS connections, Chrome refers to a list of root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a “Root Store.” CA certificates included in the Chrome Root Store are selected on the basis of publicly available and verified information, such as that within the Common CA Database (CCADB), and ongoing reviews by the Chrome Root Program.

In Chrome 105, Chrome began a platform-by-platform transition from relying on the host operating system’s Root Store to its own on Windows, macOS, ChromeOS, Linux, and Android. This change makes Chrome more secure and promotes consistent user and developer experiences across platforms. Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS. Learn more about the Chrome Root Store and Chrome Certificate Verifier here.

The Chrome Root Program Policy below establishes the minimum requirements for self-signed root CA certificates to be included as trusted in a default installation of Chrome.

Apply for Inclusion

CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using these instructions.

Moving Forward, Together

The June 2022 release (Version 1.1) of the Chrome Root Program Policy introduced the Chrome Root Program’s “Moving Forward, Together” initiative that set out to share our vision of the future that includes modern, reliable, highly agile, purpose-driven PKIs with a focus on automation, simplicity, and security.

Learn more about priorities and initiatives that may influence future versions of this policy here.

Additional Information

If you’re a Chrome user experiencing a certificate error and need help, please see this support article.

If you’re a website operator, you can learn more about why HTTPS matters and how to secure your site with HTTPS. If you’ve got a question about a certificate you’ve been issued, please contact the CA that issued it.

If you're responsible for a CA that only issues certificates to your enterprise organization, sometimes called a "private" or "locally trusted" CA, the Chrome Root Program Policy does not apply to or impact your organization’s use cases. Enterprise CAs are intended for use cases exclusively internal to an organization (e.g., a TLS server authentication certificate issued to a corporate intranet site).

Though uncommon, websites can also use certificates to identify clients (e.g., users) connecting to them. Besides ensuring it is well-formed, Chrome passes this type of certificate to the server, which then evaluates and enforces its chosen policy. The policies on this page do not apply to client authentication certificates.

Change History

Version Date Note
1.0 2020-12-20 Initial release
1.1 2022-06-01 Updated in anticipation of the future Chrome Root Program launch.

Updates include, but are not limited to:

  • future-dated applicant requirements for dedicated TLS-hierarchies and key-pair freshness
  • clarification of audit expectations
  • requirements for cross-certificate issuance notification
  • description of and requirements related to an annual self-assessment process
  • an outline of priority Chrome Root Program initiatives
1.2 2022-09-01 Updated to reflect the launch of the Chrome Root Program.

Updates include, but are not limited to:

  • removal of pre-launch discussion
  • clarifications resulting from the June 2022 Chrome CCADB survey
  • minor reorganization of normative and non-normative requirements
1.3 2023-01-06 Updated to include the CCADB Self-Assessment
1.4 2023-03-03 Updates include, but are not limited to:
  • alignment with CCADB Policy Version 1.2 and the Baseline Requirements
  • clarify requirements related to the submission of annual self assessments
  • clarify requirements to better align with program intent (e.g., CA owner policy document freshness)
  • updated audit and incident reporting requirements to promote increased transparency
  • require subordinate CA disclosures in CCADB
  • clarify CA certificate issuance notification requirements
1.5 (current) 2024-01-16 Updates include, but are not limited to:
  • incorporated CA Owner feedback in response to policy Version 1.4 (clean-ups and clarifications throughout the policy)
  • added new subsections for Root CA Key Material Freshness, Automation Support, and the Root CA Term-Limit
  • aligned incident reporting format and timelines with CCADB.org

Minimum Requirements for CAs

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this policy are to be interpreted as described in RFC 2119.

This policy considers a “CA Owner” to be the organization or legal entity that is either:

This policy considers an “Applicant” to be an organization or legal entity that has an open “Root Inclusion Request” submitted to the Chrome Root Store in the CCADB.

This policy uses the term “Chrome Root Program Participants” to describe Applicants and CA Owners with:

This policy uses the term “Externally-operated CA” to describe subordinate CA certificates issued where the organization or legal entity in possession or control of the corresponding private key capable of issuing new certificates is not under the sole control of the CA Owner included in the Chrome Root Store.

Chrome Root Program Participants MUST satisfy the requirements defined in this policy, including taking responsibility for ensuring the continued compliance of all corresponding subordinate CAs and delegated third parties participating in the Public Key Infrastructure (PKI).

Google includes or removes self-signed root CA certificates in the Chrome Root Store as it deems appropriate at its sole discretion. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. CA certificates that do not provide a broad service to all browser users will not be added to, or may be removed from the Chrome Root Store. CA certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion.

Chrome maintains a variety of mechanisms to protect its users from certificates that put their safety and privacy at risk, and is prepared to use them as necessary. A Chrome Root Program Participant’s failure to follow the minimum requirements defined in this policy may result in the corresponding 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.

The requirements included in this policy are effective immediately, unless explicitly stated as otherwise.

Any questions regarding this policy can be directed to chrome-root-program [at] google [dot] com.

1. Baseline Requirements

Chrome Root Program Participants that issue TLS server authentication certificates trusted by Chrome MUST adhere to the latest version of the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”).

This policy describes TLS server authentication certificates in Section 4 (“Dedicated TLS Server Authentication PKI Hierarchies”).

2. Chrome Root Program Participant Policies

Chrome Root Program Participants MUST accurately describe the policies and practices of their CA(s) within a Certificate Policy (CP) and corresponding Certification Practice Statement (CPS), or preferably, a single document combined as a CP/CPS.

These CA policy documents MUST be:

To promote simplicity and clarity, these CA policy documents SHOULD be:

The Chrome Root Program considers CA policy documentation in the CCADB to be authoritative. Before corresponding policy changes are put into practice, Chrome Root Program Participants:

3. Modern Infrastructures

Root CA Key Material Freshness

The Chrome Root Program will only accept a CCADB “Root Inclusion Request” from Applicant PKI hierarchies with corresponding root CA key material generated within 5 years of application to the Chrome Root Store.

Applicants MUST submit written evidence to the CCADB identifying the date(s) of the key generation ceremony and an attestation to the Applicant’s adherence to the requirements defined in Sections 6.1.1.1 (“CA Key Pair Generation”) and 6.2 (“Private Key Protection and Cryptographic Module Engineering Controls”) of the Baseline Requirements from a Qualified Auditor using an approved format, in accordance with the table below.

Audit Scheme Qualified Auditor Criteria Report Format Criteria
WebTrust an enrolled WebTrust practitioner WebTrust “Reporting on Root Key Generation” report
ETSI a member of the Accredited Conformity Assessment Bodies' Council (ACAB’c) ACAB’c Audit Attestation Letter template

If key material is not used to issue a self-signed root CA certificate on the same date it was generated, Applicants MUST present written evidence from a Qualified Auditor, attesting that keys were minimally protected in a manner consistent with the requirements defined in Section 6.2 (“Private Key Protection and Cryptographic Module Engineering Controls”) of the Baseline Requirements from the time of generation to the time the self-signed certificate was issued. Written evidence MUST be submitted to the CCADB no later than 457 calendar days (i.e., 1 year and 92 days), or 458 calendar days if the audit period falls during a leap year, from when the earliest self-signed certificate was issued.

Automation Support

Effective February 15, 2024, the Chrome Root Program will only accept CCADB “Root Inclusion Requests” from Applicant PKI hierarchies that support at least one automated solution for certificate issuance and renewal for each Baseline Requirements certificate policy OID (i.e., IV, DV, OV, EV) the corresponding hierarchy issues. This requirement does not:

The automated solution MUST minimize "hands-on" input required from humans during certificate issuance and renewal. Acceptable "hands-on" input from humans includes initial software installation and configuration, applying software updates, and updating subscriber account information as needed. Routine certificate issuance and renewal SHOULD NOT involve human input except as needed for identity or business document verification related to IV, OV, or EV certificate issuance.

For each Baseline Requirements certificate policy OID the corresponding hierarchy issues, the Applicant MUST use its automated solution to issue test TLS server authentication certificates (i.e., "automation test certificates") intended to demonstrate its automation capabilities to the Chrome Root Program. Automation test website certificates MUST be renewed at least once every 30 days, however, at any point, the Chrome Root Program may request more frequent renewal. Automation test certificates MUST be served by a publicly accessible website whose URL is disclosed to the CCADB in a Root Inclusion Request. CA Owners are encouraged to issue “Short-lived Subscriber Certificates,” as introduced in Version 2.0.1 of the Baseline Requirements, for the automation test certificates.

If at any point a self-signed root CA certificate is accepted into the Chrome Root Store after these requirements take effect and the CA Owner intends to issue a Baseline Requirements certificate policy OID not previously disclosed to the Chrome Root Program, the requirements in this section MUST be satisfied before issuing certificates containing the OID to Subscribers from the corresponding hierarchy, with the exception of automation test certificates.

Applicant PKI hierarchies SHOULD support the Automatic Certificate Management Environment (ACME) protocol. If ACME is supported by the Applicant:

While ACME support is encouraged, Applicant PKI hierarchies MAY support other automated solutions so long as the following characteristics are verifiably demonstrated to the Chrome Root Program:

Root CA Term-Limit

Effective February 15, 2024, any root CA certificate with corresponding key material generated more than 15 years ago will be removed from the Chrome Root Store on an ongoing basis.

The age of the key material will be determined by the earliest of either:

To phase-in these requirements in a manner that reduces negative impact to the ecosystem, affected root CA certificates included in the Chrome Root Store will be removed according to the schedule in the table below.

Key Material Created Approximate Removal Date
Before January 1, 2006 April 15, 2025
Between January 1, 2006 and December 31, 2007 (inclusive) April 15, 2026
Between January 1, 2008 and December 31, 2009 (inclusive) April 15, 2027
Between January 1, 2010 and December 31, 2011 (inclusive) April 15, 2028
Between January 1, 2012 and April 14, 2014 (inclusive) April 15, 2029
After April 15, 2014 15 years from generation

To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a root CA certificate past its defined term-limit on a case-by-case basis, if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate at least one year in advance of the approximate removal date.

Other circumstances may lead to the removal of a root CA certificate included in the Chrome Root Store before the completion of its term-limit (e.g., the future phase-out of root CA certificates included in the Chrome Root Store that are not dedicated to TLS server authentication use cases).

4. Dedicated TLS Server Authentication PKI Hierarchies

The Chrome Root Program will only accept CCADB “Root Inclusion Requests” from Applicant PKI hierarchies that are dedicated to TLS server authentication certificate issuance.

A dedicated PKI hierarchy is intended to serve one specific use case, for example, the issuance of TLS server authentication certificates.

To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:

  1. All corresponding subordinate CA certificates operated beneath a root CA MUST:

    • include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:
      1. id-kp-serverAuth, or
      2. id-kp-serverAuth and id-kp-clientAuth
    • NOT contain a public key corresponding to any other unexpired or non-revoked certificate that asserts different extendedKeyUsage values.
  2. All corresponding subscriber (i.e., server) certificates MUST:

    • include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:
      1. id-kp-serverAuth, or
      2. id-kp-serverAuth and id-kp-clientAuth

5. Audits

Chrome Root Program Participant CAs MUST be audited in accordance with the table below.

CA Type EKU Characteristics* Audit Criteria
Root CA N/A If WebTrust…
  • WebTrust Principles and Criteria for Certification Authorities; and
  • WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
  • [and WebTrust for CAs - EV SSL, if issuing EV]

  • or…

    If ETSI**…
  • ETSI EN 319 411-1 LCP and [DVCP or OVCP]; or
  • ETSI EN 319 411-1 [NCP or NCP+] and EVCP (if issuing EV)
  • Cross-Certified Subordinate CA Either:
  • Certificate does not include an EKU; or
  • EKU is present and includes id-kp-serverAuth or anyExtendedKeyUsage
  • TLS Subordinate CA or Technically Constrained TLS Subordinate CA Either:
  • Certificate does not include an EKU; or
  • EKU is present and includes id-kp-serverAuth or anyExtendedKeyUsage
  • Technically Constrained Non-TLS Subordinate CA EKU is present and does not include id-kp-serverAuth or anyExtendedKeyUsage. Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit).
    All others N/A

    * while existing CA certificates trusted by Chrome MAY have EKU values as described in this table, Applicant PKI hierarchies MUST remain dedicated to only TLS server authentication use cases
    ** accepted on a discretionary basis

    Annual Audits

    Chrome Root Program Participant CAs MUST retain an unbroken, contiguous audit coverage.

    Recurring complete (i.e., “full”, “full system”, or “full re-assessment”) audits MUST occur at least once every 365 calendar days (or 366 calendar days in a leap year). These audits MUST begin once a CA’s key material has been generated and MUST continue until the corresponding root CA’s key material has been destroyed or is no longer included in the Chrome Root Store.

    Ad-Hoc Audits

    When deemed necessary, the Chrome Root Program may require Chrome Root Program Participants undergo additional ad-hoc audits, including, but not limited to, instances of CA private key destruction or verification of incident remediation.

    Reporting Requirements

    Audit reports MUST:

    6. Annual Self-assessments

    CA Owners with certificates included in the Chrome Root Store MUST complete and submit an annual self-assessment to the CCADB. Instructions for completing the self-assessment are included in the required assessment template.

    A single self-assessment MAY cover multiple CAs operating under both the same CP and CPS(s), or combined CP/CPS. CAs not operated under the same CP and CPS(s) or combined CP/CPS MUST be covered in a separate self-assessment.

    The scope of the self-assessment submission MUST include:

    The self-assessment submission date is determined by the earliest appearing “BR Audit Period End Date” field specified in any of the CA Owner’s “CA Owner/Certificate” CCADB root records that are included in the Chrome Root Store.

    Chrome Root Program Participants SHOULD always use the latest available version of the self-assessment template. CA Owners MUST NOT use a version of the self-assessment template that has been superseded by more than 90 calendar days before their submission.

    7. Reporting and Responding to Incidents

    The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA’s integrity, trustworthiness, or compatibility.

    Chrome Root Program Participants MUST publicly disclose and/or respond to incident reports in Bugzilla, regardless of perceived impact. Reports MUST be submitted in accordance with the current version of this CCADB incident report format and timelines.

    While all Chrome Root Program Participants MAY participate in the incident reporting process, the CA Owner whose corresponding certificate is included in the Chrome Root Store is encouraged to disclose and/or respond to incidents on behalf of the Chrome Root Program Participants included in its PKI hierarchy.

    If the Chrome Root Program Participant has not yet publicly disclosed an incident, they MUST notify chrome-root-program [at] google [dot] com and include an initial timeline for public disclosure. Chrome uses the information in the public disclosure as the basis for evaluating incidents.

    The Chrome Root Program will evaluate every incident on a case-by-case basis, and will work with the CA Owner to identify ecosystem-wide risks or potential improvements to be made that can help prevent future incidents.

    Chrome Root Program Participants MUST be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA Owner’s response. When evaluating an incident response, the Chrome Root Program’s primary concern is ensuring that browsers, other CA Owners, users, and website developers have the necessary information to identify improvements, and that the Chrome Root Program Participant is responsive to addressing identified issues.

    Factors that are significant to the Chrome Root Program when evaluating incidents include (but are not limited to):

    Due to the incorporation of the Baseline Requirements into CA policy documents, incidents may include a prescribed follow-up action, such as revoking impacted certificates within a certain timeframe. If the Chrome Root Program Participant does not perform the required follow-up actions, or does not perform them in the expected timeframe, the Chrome Root Program Participant SHOULD file a secondary incident report describing any certificates involved, the expected timeline to complete any follow-up actions, and what changes they are making to ensure they can meet these requirements consistently in the future.

    Audit Incident Reports

    For ETSI audits, any non-conformity and/or problem identified over the course of the audit is considered an incident and MUST have an Audit Incident Report created in Bugzilla by the Chrome Root Program Participant prior to or within 7 calendar days of the AAL’s issuance date.

    For WebTrust audits, any qualification and/or modified opinion is considered an incident and MUST have an Audit Incident Report created in Bugzilla by the Chrome Root Program Participant prior to or within 7 calendar days of the Assurance Report’s issuance date.

    8. Common CA Database

    The Chrome Root Program relies on the CCADB to identify and maintain up-to-date information for Chrome Root Program Participants and the corresponding PKI hierarchies.

    Chrome Root Program Participants MUST:

    1. Follow the requirements defined in the CCADB Policy.
      • In instances where the CCADB Policy conflicts with this policy, this policy MUST take precedence.
      • When a timeline is not defined for a requirement specified within the CCADB Policy, updates MUST be submitted to the CCADB within 14 calendar days of being completed.
    2. Disclose all subordinate CA certificates capable of validating to a certificate included in the Chrome Root Store to the CCADB. Disclosure MUST take place within 7 calendar days of issuance and before the subject CA represented in the certificate begins issuing publicly-trusted certificates.
    3. Disclose revocation of all subordinate CA certificates capable of validating to a certificate included in the Chrome Root Store to the CCADB within 7 calendar days of revocation.

    9. Timely and Transparent Communications

    At any time, the Chrome Root Program may request additional information from a Chrome Root Program Participant using email or CCADB communications to verify the commitments and obligations outlined in this policy are being met, or as updates to policy requirements are being considered. Chrome Root Program Participants MUST provide the requested information within 14 calendar days unless specified otherwise.

    Notification of CA Certificate Issuance

    CA Owners included in the Chrome Root Store MUST complete the “Chrome Root Program Notification of CA Certificate Issuance” form, made available by emailing chrome-root-program [at] google [dot] com, at least 3 weeks before a CA in the corresponding hierarchy issues a CA certificate that:

    Examples of the above use cases include cross certificates and Externally-operated CA certificates.

    Such CA certificates MUST NOT be issued without the expressed approval of the Chrome Root Program.

    No other notification or approval is required.

    Notification of Procurement, Sale, or other Change Control Events

    Chrome Root Program Participants MUST NOT assume trust is transferable.

    Where permissible by law, Chrome Root Program Participants MUST notify chrome-root-program [at] google [dot] com at least 30 calendar days before any impending:

    Not limited to the circumstances above, the Chrome Root Program reserves the right to require re-application to the Chrome Root Store.