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

The change history of TLS certificate and CA requirement effective dates (CA/Browser Forum, Chrome, Mozilla): 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.

Since the initial snapshot of 2026-08-05, this register has changed on 1 further date. This register is re-checked against its sources on a schedule; a date appears below only when records were added or their values changed, so a quiet stretch means the register itself was quiet, not that nobody looked.

We keep the current verified state of each record, not the value it replaced — so each entry says which records changed and what they now state, never what they said before. Machine subscribers: poll changes.xml (Atom) or changes.json instead of re-fetching the dataset.

2026-09-24 — 18 records added or updated

• Authorization Domain Names must be derived based on the validation method to be used. · 3.2.2.4 · CA/Browser Forum TLS Baseline RequirementsNow states — Effective date: 2026-11-15; Baseline Requirements section: 3.2.2.4. (State after this change; the previous value was not stored.)
• DNSSEC validation MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. · 3.2.2.4 · CA/Browser Forum TLS Baseline RequirementsNow states — Effective date: 2026-03-15; Baseline Requirements section: 3.2.2.4. (State after this change; the previous value was not stored.)
• DNSSEC validation MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. · 4.2.2.2.2 · CA/Browser Forum TLS Baseline RequirementsNow states — Effective date: 2026-03-15; Baseline Requirements section: 4.2.2.2.2. (State after this change; the previous value was not stored.)
• CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. · 4.2.2.2.4 · CA/Browser Forum TLS Baseline RequirementsNow states — Effective date: 2026-03-15; Baseline Requirements section: 4.2.2.2.4. (State after this change; the previous value was not stored.)
• DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. · 4.2.2.2.5 · CA/Browser Forum TLS Baseline RequirementsNow states — Effective date: 2026-03-15; Baseline Requirements section: 4.2.2.2.5. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2026-06-15. (State after this change; the previous value was not stored.)
• All subscriber certificates MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. · Google Chrome Root ProgramNow states — Effective date: 2027-03-15. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2027-03-15. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2027-03-15. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2026-06-15. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2026-06-15. (State after this change; the previous value was not stored.)
• Root CA certificates with key material created between January 1, 2006 and December 31, 2007 (inclusive) will be removed from the Chrome Root Store. · Google Chrome Root ProgramNow states — Effective date: 2026-04-15. (State after this change; the previous value was not stored.)
• Root CA certificates with key material created between January 1, 2008 and December 31, 2009 (inclusive) will be removed from the Chrome Root Store. · Google Chrome Root ProgramNow states — Effective date: 2027-04-15. (State after this change; the previous value was not stored.)
• Root CA certificates with key material created between January 1, 2010 and December 31, 2011 (inclusive) will be removed from the Chrome Root Store. · Google Chrome Root ProgramNow states — Effective date: 2028-04-15. (State after this change; the previous value was not stored.)
• Root CA certificates with key material created between January 1, 2012 and April 14, 2014 (inclusive) will be removed from the Chrome Root Store. · Google Chrome Root ProgramNow states — Effective date: 2029-04-15. (State after this change; the previous value was not stored.)
• The Chrome Root Program will phase-out PKI hierarchies found in violation of subordinate CA extendedKeyUsage requirements. · Google Chrome Root ProgramNow states — Effective date: 2026-06-15. (State after this change; the previous value was not stored.)
• 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. · Google Chrome Root ProgramNow states — Effective date: 2027-03-15. (State after this change; the previous value was not stored.)
• The Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner. · Google Chrome Root ProgramNow states — Effective date: 2027-09-15. (State after this change; the previous value was not stored.)

2026-08-05 — Initial snapshot — 28 records

The first verified snapshot: every record was new on this date. The full register is on the dataset page.

• 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. · 3.2.2.4 and 3.2.2.5 · CA/Browser Forum TLS Baseline 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. · 3.2.2.4 and 3.2.2.5 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information. · 3.2.2.4 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. · 3.2.2.4 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates. · 3.2.2.4 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. · 3.2.2.4 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates. · 3.2.2.5.3 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified. · 3.2.2.9 · CA/Browser Forum TLS Baseline Requirements
• Domain Name and IP Address validation maximum data reuse period is 10 days. · 4.2.1 · CA/Browser Forum TLS Baseline Requirements
• Domain Name and IP Address validation maximum data reuse period is 100 days. · 4.2.1 · CA/Browser Forum TLS Baseline Requirements
• Domain Name and IP Address validation maximum data reuse period is 200 days. · 4.2.1 · CA/Browser Forum TLS Baseline Requirements
• Subject Identity Information validation maximum data reuse period is 398 days. · 4.2.1 · CA/Browser Forum TLS Baseline Requirements
• CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657. · 4.2.2.1.2 · CA/Browser Forum TLS Baseline 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 · 4.2.2.1.2 · CA/Browser Forum TLS Baseline Requirements
• CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix. · 4.2.2 · CA/Browser Forum TLS Baseline Requirements
• The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements. · 4.3.1.2 · CA/Browser Forum TLS Baseline Requirements
• Subscriber Certificate OCSP responses MUST be available 15 minutes after issuance. · 4.9.9 · CA/Browser Forum TLS Baseline Requirements
• Audit logs of verification activity MUST include specific information. · 5.4.1 · CA/Browser Forum TLS Baseline Requirements
• CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. · 5.7.1.2 · CA/Browser Forum TLS Baseline Requirements
• Maximum validity period of Subscriber Certificates is 100 days. · 6.3.2 · CA/Browser Forum TLS Baseline Requirements

… and 8 more records on this date. The full current state of every record is in data.json.