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.
No changes yet since the initial snapshot of . 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.
— Initial snapshot — 45 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.
- 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.
- CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. CAs MUST rely on IANA resources for identifying Domain Contact information.
- CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates.
- CAs MUST NOT rely on Methods 3.2.2.4.2 and 3.2.2.4.15 to issue Subscriber Certificates.
- CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.
- 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.
- CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates.
- CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups.
- 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.
- DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.
- CAs MUST corroborate the results of domain validation and CAA checks from multiple Network Perspectives where specified.
- Domain Name and IP Address validation maximum data reuse period is 10 days.
- Domain Name and IP Address validation maximum data reuse period is 100 days.
- Domain Name and IP Address validation maximum data reuse period is 200 days.
- Subject Identity Information validation maximum data reuse period is 398 days.
- CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.
- 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
- CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix.
- The CA SHALL implement a Linting process to test the technical conformity of the to-be-issued Certificate with these Requirements.
… and 25 more records on this date. The full current state of every record is in data.json.