Forward-dated schedule of when each TLS certificate and certificate authority requirement takes effect, and which programme it binds. Each record is one requirement with its effective date, the Baseline Requirements section it amends, and the authority imposing it. Covers the CA/Browser Forum TLS Baseline Requirements effective-date table, the Google Chrome Root Program policy, and the Mozilla Root Store Policy. Answers 'when does the 200 day certificate lifetime take effect', 'TLS certificate maximum validity 100 days date', '47 day certificates 2029 timeline', 'when does domain validation reuse drop to 200 days', 'SC-081 phased schedule', and 'when do CAs have to do DNSSEC validation'. The dates changed recently and change again with every ballot, so an answer from model memory describes a world that has already moved; the maximum subscriber certificate validity drops to 200 days on 2026-03-15 and to 100 days on 2027-03-15, and the domain-validation reuse period and the subject-identity reuse period fall on different schedules to each other.

Facts extracted from freely published governance documents. The CA/Browser Forum publishes the Baseline Requirements publicly for implementation; the Chrome Root Program policy and Mozilla Root Store Policy are published openly by their respective root programmes. Each record quotes a short verbatim span and links back to the document section.

TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on Methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, and 3.2.2.5.5 to issue Subscriber Certificates.

**Effective date:** 2027-03-15

**Baseline Requirements section:** 3.2.2.4 and 3.2.2.5

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2027-03-15 | 3.2.2.4 and 3.2.2.5 | CAs MUST NOT rely on Methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, and 3.2.2.5.5 to issue Subscriber Certificates.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on Methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, and 3.2.2.5.5 to issue Subscriber Certificates. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates.

**Effective date:** 2028-03-15

**Baseline Requirements section:** 3.2.2.4 and 3.2.2.5

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2028-03-15 | 3.2.2.4 and 3.2.2.5 | CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information.

**Effective date:** 2025-01-15

**Baseline Requirements section:** 3.2.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-01-15 | 3.2.2.4 | CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.4 | CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates.

**Effective date:** 2025-07-15

**Baseline Requirements section:** 3.2.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-07-15 | 3.2.2.4 | CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates.

**Effective date:** 2027-03-15

**Baseline Requirements section:** 3.2.2.5.3

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2027-03-15 | 3.2.2.5.3 | CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.8.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.8.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 3.2.2.8.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified.

**Effective date:** 2025-03-15

**Baseline Requirements section:** 3.2.2.9

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-03-15 | 3.2.2.9 | CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Domain Name and IP Address validation maximum data reuse period is 10 days.

**Effective date:** 2029-03-15

**Baseline Requirements section:** 4.2.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Domain Name and IP Address validation maximum data reuse period is 10 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Domain Name and IP Address validation maximum data reuse period is 100 days.

**Effective date:** 2027-03-15

**Baseline Requirements section:** 4.2.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Domain Name and IP Address validation maximum data reuse period is 100 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Domain Name and IP Address validation maximum data reuse period is 200 days.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 4.2.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Domain Name and IP Address validation maximum data reuse period is 200 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Subject Identity Information validation maximum data reuse period is 398 days.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 4.2.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Subject Identity Information validation maximum data reuse period is 398 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.

**Effective date:** 2027-03-15

**Baseline Requirements section:** 4.2.2.1.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> CAs MUST process the accounturi and validationmethods parameters as specified in <https://datatracker.ietf.org/doc/html/rfc8657> RFC 8657

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** If the CA does not identify the Subscriber account via an ACME Account URL as described in RFC 8555, the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the acct URI scheme defined in RFC 7565

**Effective date:** 2027-03-15

**Baseline Requirements section:** 4.2.2.1.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the acct URI scheme defined in

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

If the CA does not identify the Subscriber account via an ACME Account URL as described in RFC 8555, the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the acct URI scheme defined in RFC 7565 — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 4.2.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 4.2.2 | CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements.

**Effective date:** 2025-03-15

**Baseline Requirements section:** 4.3.1.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-03-15 | 4.3.1.2 | The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance.

**Effective date:** 2025-01-15

**Baseline Requirements section:** 4.9.9

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-01-15 | 4.9.9 | Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Audit logs of verification activity MUST include specific information.

**Effective date:** 2026-07-15

**Baseline Requirements section:** 5.4.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-07-15 | 5.4.1 | Audit logs of verification activity MUST include specific information.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Audit logs of verification activity MUST include specific information. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements.

**Effective date:** 2025-12-01

**Baseline Requirements section:** 5.7.1.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Maximum validity period of Subscriber Certificates is 100 days.

**Effective date:** 2027-03-15

**Baseline Requirements section:** 6.3.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** Subscriber Certificates only

> 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Maximum validity period of Subscriber Certificates is 100 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Maximum validity period of Subscriber Certificates is 200 days.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 6.3.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** Subscriber Certificates only

> 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Maximum validity period of Subscriber Certificates is 200 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Maximum validity period of Subscriber Certificates is 47 days.

**Effective date:** 2029-03-15

**Baseline Requirements section:** 6.3.2

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** Subscriber Certificates only

> 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Maximum validity period of Subscriber Certificates is 47 days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4.

**Effective date:** 2026-03-15

**Baseline Requirements section:** 7.1.2.4

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-03-15 | 7.1.2.4 | CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Sunset all remaining use of SHA-1 in Certificates and CRLs.

**Effective date:** 2026-09-15

**Baseline Requirements section:** 7.1.3.2.1

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2026-09-15 | 7.1.3.2.1 | Sunset all remaining use of SHA-1 in Certificates and CRLs.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

Sunset all remaining use of SHA-1 in Certificates and CRLs. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits.

**Effective date:** 2025-03-15

**Baseline Requirements section:** 8.7

**Authority:** CA/Browser Forum TLS Baseline Requirements

**Scope:** all publicly-trusted CAs issuing TLS server certificates

> 2025-03-15 | 8.7 | The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits.

Source: <https://cabforum.org/working-groups/server/baseline-requirements/requirements/>

The CA SHOULD use a Linting process to test the technical accuracy of already issued Certificates against the sample set chosen for Self-Audits. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** A Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy.

**Effective date:** 2026-06-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Effective June 15, 2026 , a Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy.

Source: <https://googlechrome.github.io/chromerootprogram/>

A Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** All subscriber certificates MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

**Effective date:** 2027-03-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> All corresponding subscriber certificates issued on or after March 15, 2027 , MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

Source: <https://googlechrome.github.io/chromerootprogram/>

All subscriber certificates MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** All unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution.

**Effective date:** 2027-03-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Effective March 15, 2027 , all unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution

Source: <https://googlechrome.github.io/chromerootprogram/>

All unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates, and issue Automation Test Certificates renewed at least once every 30 calendar days.

**Effective date:** 2027-03-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> effective March 15, 2027 , for each CCADB root certificate record corresponding to a root included in the Chrome Root Store, CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates.

Source: <https://googlechrome.github.io/chromerootprogram/>

CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates, and issue Automation Test Certificates renewed at least once every 30 calendar days. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CA Owners MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as Usable or Qualified before issuing the corresponding certificate.

**Effective date:** 2026-06-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Effective June 15, 2026 , CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as

Source: <https://googlechrome.github.io/chromerootprogram/>

CA Owners MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as Usable or Qualified before issuing the corresponding certificate. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program.

**Effective date:** 2026-06-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Before June 15, 2026 , CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program.

Source: <https://googlechrome.github.io/chromerootprogram/>

CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Root CA certificates with key material created between January 1, 2006 and December 31, 2007 (inclusive) will be removed from the Chrome Root Store.

**Effective date:** 2026-04-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Between January 1, 2006 and December 31, 2007 (inclusive) | April 15, 2026

Source: <https://googlechrome.github.io/chromerootprogram/>

Root CA certificates with key material created between January 1, 2006 and December 31, 2007 (inclusive) will be removed from the Chrome Root Store. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Root CA certificates with key material created between January 1, 2008 and December 31, 2009 (inclusive) will be removed from the Chrome Root Store.

**Effective date:** 2027-04-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Between January 1, 2008 and December 31, 2009 (inclusive) | April 15, 2027

Source: <https://googlechrome.github.io/chromerootprogram/>

Root CA certificates with key material created between January 1, 2008 and December 31, 2009 (inclusive) will be removed from the Chrome Root Store. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Root CA certificates with key material created between January 1, 2010 and December 31, 2011 (inclusive) will be removed from the Chrome Root Store.

**Effective date:** 2028-04-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Between January 1, 2010 and December 31, 2011 (inclusive) | April 15, 2028

Source: <https://googlechrome.github.io/chromerootprogram/>

Root CA certificates with key material created between January 1, 2010 and December 31, 2011 (inclusive) will be removed from the Chrome Root Store. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** Root CA certificates with key material created between January 1, 2012 and April 14, 2014 (inclusive) will be removed from the Chrome Root Store.

**Effective date:** 2029-04-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Between January 1, 2012 and April 14, 2014 (inclusive) | April 15, 2029

Source: <https://googlechrome.github.io/chromerootprogram/>

Root CA certificates with key material created between January 1, 2012 and April 14, 2014 (inclusive) will be removed from the Chrome Root Store. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** The Chrome Root Program will phase-out PKI hierarchies found in violation of subordinate CA extendedKeyUsage requirements.

**Effective date:** 2026-06-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Beginning June 15, 2026 , the Chrome Root Program will phase-out PKI hierarchies found in violation of the below requirements.

Source: <https://googlechrome.github.io/chromerootprogram/>

The Chrome Root Program will phase-out PKI hierarchies found in violation of subordinate CA extendedKeyUsage requirements. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** The Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB.

**Effective date:** 2027-03-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Beginning March 15, 2027 , the Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB.

Source: <https://googlechrome.github.io/chromerootprogram/>

The Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** The Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner.

**Effective date:** 2027-09-15

**Authority:** Google Chrome Root Program

**Scope:** CAs included in the Chrome Root Store

> Effective September 15, 2027 , the Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner.

Source: <https://googlechrome.github.io/chromerootprogram/>

The Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** For each annual audit period beginning on or after July 1, 2027, each CA operator with a CA certificate included in Mozilla's root store with the websites trust bit enabled MUST obtain a Detailed Controls Report (DCR).

**Effective date:** 2027-07-01

**Authority:** Mozilla Root Store Policy

**Scope:** CA operators whose certificates are included in Mozilla's root store with the websites trust bit enabled

> For each annual audit period beginning on or after July 1, 2027, each CA operator with a CA certificate included in our root store with the websites trust bit enabled MUST obtain a Detailed Controls Report (DCR).

Source: <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>

For each annual audit period beginning on or after July 1, 2027, each CA operator with a CA certificate included in Mozilla's root store with the websites trust bit enabled MUST obtain a Detailed Controls Report (DCR). — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** WebTrust "Principles and Criteria for Certification Authorities - Network Security" Version 1.7 permitted for audit periods ending before 2026-11-29; Version 2.0.5 required thereafter.

**Effective date:** 2026-11-29

**Authority:** Mozilla Root Store Policy

**Scope:** CA operators whose certificates are included in Mozilla's root store

> Version 1.7 permitted for audit periods ending before 2026-11-29

Source: <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>

WebTrust "Principles and Criteria for Certification Authorities - Network Security" Version 1.7 permitted for audit periods ending before 2026-11-29; Version 2.0.5 required thereafter. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)


**Requirement:** WebTrust "Principles and Criteria for Certification Authorities - SSL Baseline" Version 2.9 permitted for audit periods ending before 2026-11-29; WebTrust TLS Baseline Version 2.10 required thereafter.

**Effective date:** 2026-11-29

**Authority:** Mozilla Root Store Policy

**Scope:** CA operators whose certificates are included in Mozilla's root store

> Version 2.9 permitted for audit periods ending before 2026-11-29

Source: <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>

WebTrust "Principles and Criteria for Certification Authorities - SSL Baseline" Version 2.9 permitted for audit periods ending before 2026-11-29; WebTrust TLS Baseline Version 2.10 required thereafter. — TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla)