TLS Certificate Ecosystem History and Timeline - Certificate Authorities, Automation, and Shrinking Certificate Lifetimes
First Published:
Last Updated:
Two questions bring most operators to this topic, and both have precise answers that are surprisingly hard to assemble. The first is "how many days will my certificate be valid, and when exactly does that change?" The second is "at what point does renewing certificates by hand stop being viable?" The answers live in CA/Browser Forum ballots, in the revision and compliance-date tables of the Baseline Requirements, in the change histories of the Chrome, Mozilla, and Apple root programs, and in IETF RFCs. No single page ties them together with a source for each fact, which is what this article sets out to be.
The most important thing to know is that this is no longer a future problem. The first reduction has already happened: certificates issued on or after 2026-03-15 must not have a validity period greater than 200 days, and the maximum reuse period for domain validation data dropped to 200 days on the same date. The remaining steps — 100 days in 2027 and 47 days in 2029 — are already written into the Baseline Requirements.
This article traces the lineage of those decisions, from the first IETF profile of X.509 for the Internet through to the schedule that runs to 2029. It is a chronology of governance and operational practice, not a history of the TLS protocol itself, and it is deliberately vendor-neutral: no certificate authority is recommended, compared, or evaluated here.
Companion articles on hidekazu-konishi.com:
- Major Security Vulnerabilities History and Timeline
- HTTP Security Headers Complete Reference
- Cryptography Glossary for Engineers
- Indie Developer Guide from Domain Setup to Deploy
- SSL/TLS Certificate Decoder (Tool)
- Email Authentication History and Timeline (SPF, DKIM, DMARC, and BIMI) - where MTA-STS makes mail transport depend on the certificate rules described here
Background and Method of Creating the TLS Certificate Ecosystem Timeline
The reason for building this timeline is that the certificate ecosystem is governed by three different kinds of body, each of which publishes in a different place and in a different form. Reconstructing "who decided what, and from when does it apply" therefore means reading three separate archives side by side.- The CA/Browser Forum is a voluntary association of certificate issuers and certificate consumers (browser and application vendors). It adopts the Baseline Requirements for publicly trusted TLS server certificates through numbered ballots, and each adopted ballot produces a new version of the requirements with its own effective date.
- Root programs — Chrome, Mozilla, Apple, and Microsoft — decide which CA certificates ship in their products. Each publishes its own policy, and those policies can and do impose requirements above the Baseline Requirements.
- The IETF standardizes the protocols and formats the ecosystem is built on: the X.509 certificate profile, Certificate Transparency, ACME, CAA, and the revocation mechanisms.
- Tracking the decisions that shaped the publicly trusted TLS certificate ecosystem and organizing the transition of requirements over time.
- Summarizing the current overall picture of certification authorities, validation, transparency, automation, and revocation.
It deliberately excludes the version history of the TLS protocol itself, which is a separate subject and is touched on only where it directly changed certificate practice; pricing and commercial terms; recommendations or comparisons between certificate authorities; and the details of post-quantum cryptography, which belong to a dedicated timeline.
Date types. Because "when a rule was agreed" and "when a rule started to bite" are different questions — and the gap between them is often a year or more — every row states which kind of date it carries, on the second line of the Date column.
- Ballot result — the date on which the CA/Browser Forum published the outcome of a ballot.
- Effective date — the date from which a requirement applies, as listed in the Baseline Requirements.
- Policy published — the publication date of a root program policy version or browser policy change.
- Guidelines published — the document date of a CA/Browser Forum guideline.
- RFC published — the publication month of an IETF RFC.
- Operator milestone — a change in what a certificate authority actually offered or operated.
- Advisory — the publication of a security advisory or incident disclosure.
- Scheduled — a date that has not yet arrived. These rows describe requirements that are already written into the Baseline Requirements or a root program policy but are not yet in force.
YYYY-MM. Every other row uses YYYY-MM-DD. Ballot rows are dated by the day the Forum published the result, which is the date on the linked page; the Baseline Requirements separately record an adoption date and an effective date for the same ballot, and where the effective date matters it is given its own row.Source policy. This timeline is built from primary sources only: CA/Browser Forum ballot pages and the Baseline Requirements themselves, root program policies published by Google, Mozilla, and Apple, RFCs from the RFC Editor, and certificate authority announcements published by the operator concerned. Vendor explainers, news coverage, and summary articles are not used as the source of record for any date or number. Where a certificate authority or browser incident appears, it appears only as the fact that a decision was taken and only as stated in the official announcement; this article does not evaluate, rank, or criticize the parties involved.
This timeline primarily references the following sources.
- CA/Browser Forum Baseline Requirements
- CA/Browser Forum Server Certificate Working Group ballots
- Chrome Root Program Policy
- Mozilla Root Store Policy
- Apple: About upcoming limits on trusted certificates
- RFC Editor
- Let's Encrypt blog
In other words, please note that the items on this timeline are not all changes to the Baseline Requirements or to root program policies, but are representative milestones that I have picked out.
TLS Certificate Ecosystem Historical Timeline (Updates from January 1999)
Here is the chronological timeline, from the first IETF profile of X.509 for the Internet through to the reductions scheduled for 2029. Each row links to the ballot, requirement, policy, RFC, or announcement that is the source of record for it, and the second line of the Date column states what kind of date it is.1999 | 2007 | 2008 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026 | 2027 | 2028 | 2029
* You can sort the table by clicking on the column name.| Date | Event |
|---|---|
| 1999-01 RFC published | RFC 2459 publishes the first IETF profile of X.509 for the Internet. It profiles X.509 version 3 certificates and version 2 certificate revocation lists for Internet use, establishing the certificate structure the Web PKI still relies on. Source: RFC 2459 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile. |
| 1999-06 RFC published | RFC 2560 defines the Online Certificate Status Protocol (OCSP). OCSP lets a relying party ask an authority about the status of a single certificate instead of downloading a complete revocation list — the design that dominated revocation checking for the next two decades. Source: RFC 2560 - X.509 Internet PKI Online Certificate Status Protocol. |
| 2007-06-07 Guidelines published | The CA/Browser Forum publishes version 1.0 of the Extended Validation Certificate Guidelines. EV established a common, audited identity-vetting standard for organizations, and browsers of the era surfaced it with a distinct address bar treatment. Source: Guidelines for the Issuance and Management of Extended Validation Certificates, Version 1.0 (PDF). |
| 2008-05 RFC published | RFC 5280 becomes the current Internet X.509 certificate profile. It obsoletes RFC 3280, the successor to RFC 2459. Its Section 4.1.2.5 definition of the validity period — "the period of time from notBefore through notAfter, inclusive" — is the definition every later lifetime rule refers back to. Source: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile. |
| 2011-08-29 Advisory | Mozilla reports a fraudulently issued certificate for a Google domain. The certificate had been issued by a certificate authority operating in the Netherlands, and Mozilla described the action taken in its products. Source: Fraudulent *.google.com Certificate (Mozilla Security Blog). |
| 2011-09-02 Policy published | Mozilla announces the permanent removal of that authority's root certificates from its root store. The episode is the reference case for why root programs need a way to see what a certificate authority has actually issued — the need that Certificate Transparency was later designed to meet. Source: DigiNotar Removal Follow Up (Mozilla Security Blog). |
| 2011-11-22 Ballot result | Ballot 62 adopts the Baseline Requirements version 1.0, with an effective date of 1 July 2012. For the first time, publicly trusted TLS certificates had a single written floor covering validation, certificate contents, revocation, and CA operations, which browser vendors were asked to fold into their root program requirements. Source: Ballot 62 - Adopt Baseline Requirements Draft 50. |
| 2012-07-01 Effective date | The Baseline Requirements take effect. The Requirements state that, except where explicitly noted, they apply only to relevant events occurring on or after this date, which they describe as their original effective date. Source: CA/Browser Forum Baseline Requirements. |
| 2013-01 RFC published | RFC 6844 defines the Certification Authority Authorization (CAA) DNS resource record. CAA lets a domain name holder publish which certificate authorities are permitted to issue for the domain, turning issuance authorization into something the domain owner can state in DNS. This is the original specification; it was obsoleted in 2019 by RFC 8659, which is the current definition. Source: RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record. |
| 2013-06 RFC published | RFC 6962 defines Certificate Transparency. CT specifies append-only public logs of issued certificates, with Signed Certificate Timestamps (SCTs) as evidence of submission, so that domain owners and root programs can observe issuance rather than take a CA's word for it. It was published as an Experimental specification. Source: RFC 6962 - Certificate Transparency. |
| 2013-06 RFC published | RFC 6960 becomes the current OCSP specification. It obsoletes RFC 2560 and remains the reference for OCSP responder behaviour. Source: RFC 6960 - X.509 Internet PKI Online Certificate Status Protocol. |
| 2014-04-07 Advisory | OpenSSL publishes an advisory for a read overrun in the TLS heartbeat extension. Because the flaw could expose memory contents from a running server, operators had to treat private keys as potentially disclosed, producing one of the largest reissuance and revocation events in the history of the Web PKI. The vulnerability itself is covered in my Major Security Vulnerabilities History and Timeline. Source: OpenSSL Security Advisory, 7 April 2014. |
| 2014-10-14 Ballot result | Ballot 125 brings CAA into the Baseline Requirements. At this stage the obligation is disclosure rather than enforcement: certificate authorities were given up to six months to state in their certificate policy or certification practice statement the degree to which they implement CAA. Source: Ballot 125 - CAA Records (passed). |
| 2014-10-16 Ballot result | Ballot 118 sets the SHA-1 sunset. From 1 January 2016, certificate authorities must not issue new subscriber certificates or subordinate CA certificates using the SHA-1 hash algorithm. Source: Ballot 118 - SHA-1 Sunset (passed). |
| 2014-11-18 Operator milestone | The Internet Security Research Group announces Let's Encrypt. The plan was a certificate authority issuing domain-validated certificates through an automated protocol, with no manual steps between requesting and installing a certificate. Automation, more than anything else, is what made the later lifetime reductions arguable at all. Source: Let's Encrypt: Delivering SSL/TLS Everywhere. |
| 2015-04-01 Effective date | The 39-month maximum validity period applies from this date. The pre-2017 text of Baseline Requirements Section 6.3.2 capped subscriber certificates issued after 1 April 2015 at 39 months, down from the earlier 60-month ceiling. The superseded wording is quoted in full in the text of Ballot 185. Source: Ballot 185 - Limiting the Lifetime of Certificates. |
| 2015-09-14 Operator milestone | Let's Encrypt issues its first certificate. Source: Our First Certificate Is Now Live. |
| 2015-10-19 Operator milestone | Let's Encrypt's intermediates are cross-signed by an already trusted root. Cross-signing meant its certificates were accepted by existing browsers immediately, rather than after the years it takes for a new root to propagate into shipping software. Source: Let's Encrypt is Trusted. |
| 2015-11-09 Operator milestone | Let's Encrypt publishes its rationale for 90-day certificate lifetimes. The stated reasons were limiting the damage from key compromise and mis-issuance, and forcing automation. It is essentially the argument the wider industry adopted a decade later. Source: Why ninety-day lifetimes for certificates?. |
| 2015-12-03 Operator milestone | Let's Encrypt enters public beta, making automated issuance available without an invitation. Source: Entering Public Beta. |
| 2016-04-12 Operator milestone | Let's Encrypt leaves beta. Source: Leaving Beta, New Sponsors. |
| 2016-08-05 Ballot result | Ballot 169 replaces open-ended domain validation with an explicit list of approved methods, effective 1 March 2017. The clause permitting "any other method of confirmation which has at least the same level of assurance" was removed in favour of an enumerated set. Enumerating the methods is what later made it possible to retire them one at a time. Source: Ballot 169 - Revised Validation Requirements. |
| 2017-02-24 Ballot result | Ballot 185, proposing a substantial reduction in certificate lifetimes, fails. Among certificate issuers one voted in favour and twenty-four against; among certificate consumers the vote was evenly split. Source: Ballot 185 - Limiting the Lifetime of Certificates. |
| 2017-03-08 Ballot result | Ballot 187 makes CAA checking mandatory, with an effective date of 8 September 2017. From that point a CAA record is not advisory: a compliant CA must retrieve and honour it before issuing. Source: Ballot 187 - Make CAA Checking Mandatory. |
| 2017-03-17 Ballot result | Ballot 193 passes, reducing the maximum validity period to 825 days. The ballot cut the maximum lifetime for DV and OV certificates from 39 months to 825 days and the maximum reuse period for vetting data from 39 months to 27 months. It passed with every voting certificate issuer in favour, three weeks after Ballot 185 had failed — the clearest illustration that the disagreement was about pace, not direction. Source: Ballot 193 - 825-day Certificate Lifetimes. |
| 2017-05-03 Ballot result | Ballot 197 clarifies the effective date for the reduced reuse period. Ballot 193 had specified 1 March 2018 for the validity period but not for the reuse of vetting data under Section 4.2.1; Ballot 197 confirmed that the same date applies. Source: Ballot 197 - Effective Date of Ballot 193 Provisions. |
| 2017-09-11 Policy published | Chrome publishes a dated plan for phasing out trust in one large certificate authority's existing infrastructure. The post states that the plan followed discussion in the root store community, and that the certificate authority's PKI business was subsequently transitioned to another operator. The lasting effect on the ecosystem was procedural: it established that a root program can schedule the removal of trust from infrastructure at scale, on a published timetable. Source: Chrome's Plan to Distrust Symantec Certificates (Google Security Blog). |
| 2018-03-01 Effective date | The 825-day maximum validity period and the 27-month vetting data reuse period take effect. Source: CA/Browser Forum Baseline Requirements, Section 1.2.1 Revisions. |
| 2018-04-30 Policy published | Chrome requires Certificate Transparency for all publicly trusted TLS certificates issued after this date. A certificate that is not accompanied by SCTs satisfying the Chrome CT policy simply fails to validate. Transparency stopped being an optional signal and became a condition of trust. Source: Certificate Transparency in Chrome. |
| 2018-08-06 Operator milestone | Let's Encrypt's own root is trusted by all major root programs, removing its dependence on cross-signing. Source: Let's Encrypt Root Trusted By All Major Root Programs. |
| 2019-03 RFC published | RFC 8555 standardizes the Automatic Certificate Management Environment (ACME). Automated issuance ceased to be one authority's protocol and became an IETF standard that any certificate authority or client could implement — the precondition for every lifetime reduction that followed. Source: RFC 8555 - Automatic Certificate Management Environment (ACME). |
| 2019-09-10 Ballot result | Ballot SC22v2, proposing a 397-day maximum validity period, fails. All seven voting certificate consumers were in favour; certificate issuers returned 11 in favour and 20 against, short of the required two-thirds. This is the second time a lifetime reduction was voted down. Source: Ballot SC022v2 - Reduce Certificate Lifetimes. |
| 2019-10-22 Policy published | Firefox 70 moves the Extended Validation indicator out of the address bar. The EV indicator was relocated to the identity panel that appears when the lock icon is clicked, ending the era in which EV had a distinct, always-visible browser treatment. Source: Firefox 70.0 release notes. |
| 2019-11 RFC published | RFC 8659 replaces RFC 6844 as the definition of the CAA record, and RFC 8657 adds the account and validation method parameters. RFC 8659 obsoletes the original CAA specification and is the document the Baseline Requirements' CAA obligations refer to today. RFC 8657 defines the accounturi and validationmethods parameters, which certificate authorities are required to process from 2027-03-15 under Ballot SC-098v2. Sources: RFC 8659 - DNS Certification Authority Authorization (CAA) Resource Record, RFC 8657 - Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding. |
| 2020-07-16 Ballot result | Ballot SC31 (Browser Alignment) folds root program requirements into the Baseline Requirements, including the 398-day maximum validity period. Where a lifetime reduction had twice failed as a standalone ballot, it passed as part of aligning the Requirements with rules the root programs had already adopted independently. Source: Ballot SC031 - Browser Alignment. |
| 2020-09-01 Effective date | Apple's 398-day limit takes effect. TLS server certificates issued on or after 1 September 2020 00:00 GMT/UTC must not have a validity period greater than 398 days; Apple recommends a maximum of 397 days, and states that connections to servers violating the requirement will fail. The limit applies to certificates issued from the root CAs preinstalled with Apple's operating systems, not to user-added or administrator-added roots. Source: About upcoming limits on trusted certificates (Apple Support). |
| 2020-12-20 Policy published | The Chrome Root Program Policy version 1.0 is published, ahead of Chrome operating its own root store. Source: Chrome Root Program Policy, Change History. |
| 2021-04-22 Ballot result | Ballot SC42 aligns the domain validation data reuse period with the certificate lifetime at 398 days. Keeping the two numbers equal became a design principle: a certificate should never outlive the evidence that authorized it by more than one issuance cycle. Source: Ballot SC042 - 398-day Re-use Period. |
| 2021-12 RFC published | RFC 9162 publishes Certificate Transparency version 2.0, obsoleting RFC 6962. Source: RFC 9162 - Certificate Transparency Version 2.0. |
| 2022-09-01 Policy published | Chrome Root Program Policy version 1.2 reflects the launch of the Chrome Root Store. Chrome began maintaining its own list of trusted roots and its own certificate verifier rather than deferring to the host operating system, making its policy directly enforceable. Source: Chrome Root Program Policy, Change History. |
| 2022-09-07 Operator milestone | Let's Encrypt describes its move to publishing certificate revocation lists. The post frames CRLs, combined with browser-side compression schemes, as the practical replacement for per-certificate OCSP queries. Source: A New Life for Certificate Revocation Lists. |
| 2023-07-14 Ballot result | Ballot SC63 makes OCSP optional, requires CRLs, and defines the short-lived certificate. The ballot allowed certificate authorities to stop operating OCSP responders, made CRL publication mandatory, and introduced the "Short-lived Subscriber Certificate" — initially a certificate with a validity period of 10 days or less, which a CA is permitted but not required to revoke. It is the first time the Requirements gave automated operators an explicit dispensation. Source: Ballot SC063v4 - Make OCSP Optional, Require CRLs, and Incentivize Automation. |
| 2024-01-16 Policy published | Chrome Root Program Policy version 1.5 adds root CA key material freshness, automation support, and a root CA term limit. Source: Chrome Root Program Policy, Change History. |
| 2024-03-14 Operator milestone | Let's Encrypt introduces Sunlight, a Certificate Transparency log implementation built on static tiles. Serving log data as static files rather than through the RFC 6962 API was aimed at making logs substantially cheaper and simpler to operate, which matters because shorter lifetimes mean more certificates and therefore more log entries. Source: Introducing Sunlight, a CT implementation built for scalability, ease of operation, and reduced cost. |
| 2024-03-15 Effective date | OCSP becomes optional, CRLs become mandatory, and the short-lived certificate definition takes effect. Certificates issued on or after this date with a validity period of 10 days or less qualify as Short-lived Subscriber Certificates. Source: CA/Browser Forum Baseline Requirements, Section 1.2.1 Revisions. |
| 2024-07-23 Operator milestone | Let's Encrypt states its intent to end its OCSP service and rely on CRLs. Source: Intent to End OCSP Service. |
| 2024-08-05 Ballot result | Ballot SC67 requires Multi-Perspective Issuance Corroboration. Domain validation and CAA checks must be corroborated from multiple network perspectives, so that an attacker who can influence routing or DNS resolution at one vantage point cannot alone obtain a certificate. The compliance date is 15 March 2025. Source: Ballot SC067v3 - Require Multi-Perspective Issuance Corroboration. |
| 2024-08-05 Ballot result | Ballot SC75 requires pre-signing linting. Certificate authorities must run a linting process against the to-be-issued certificate, so that profile violations are caught before signing rather than discovered afterwards. Source: Ballot SC075 - Pre-sign Linting. |
| 2024-11-14 Ballot result | Ballot SC80 sunsets the use of WHOIS to identify domain contacts, together with the validation methods that depended on it. Source: Ballot SC080v3 - Sunset the use of WHOIS to identify Domain Contacts. |
| 2025-01-09 Operator milestone | Let's Encrypt announces certificate profile selection in ACME. Selecting a named profile in the ACME client is the mechanism that later allowed subscribers to opt into shorter lifetimes on their own schedule instead of being moved all at once. Source: Announcing Certificate Profile Selection. |
| 2025-01-16 Operator milestone | Let's Encrypt announces plans for six-day certificates and for certificates covering IP addresses. Source: Announcing Six Day and IP Address Certificate Options in 2025. |
| 2025-02-20 Operator milestone | Let's Encrypt issues its first six-day certificate. Source: We Issued Our First Six Day Cert. |
| 2025-03-12 Policy published | Mozilla publishes Root Store Policy version 3.0, effective 15 March 2025. Its stated focus is delayed certificate revocation: clearer revocation expectations, improved incident reporting, subscriber education, revocation planning, and automated issuance so that replacement can be handled promptly and at scale. Source: Enhancing CA Practices: Key Updates in Mozilla Root Store Policy, v3.0. |
| 2025-03-15 Effective date | Multi-Perspective Issuance Corroboration and pre-issuance linting become mandatory. From this date certificate authorities must corroborate domain validation and CAA checks from multiple network perspectives where specified, and must implement a linting process to test the technical conformity of the to-be-issued certificate. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
| 2025-04-11 Ballot result | Ballot SC-081v3 passes, introducing the schedule that reduces certificate validity and validation data reuse periods. Voting ran from 4 to 11 April 2025 and closed with 25 certificate issuers in favour, none against and five abstaining, and all four voting certificate consumers in favour. This single ballot is the source of every remaining date in this timeline that concerns how long a certificate may live. Source: Ballot SC081v3 - Introduce Schedule of Reducing Validity and Data Reuse Periods. |
| 2025-06 RFC published | RFC 9773 standardizes the ACME Renewal Information (ARI) extension. ARI lets an ACME server suggest to a client when it should renew. As lifetimes shrink, a renewal interval hard-coded in a client becomes a liability; ARI replaces that guess with a signal from the issuer. Source: RFC 9773 - ACME Renewal Information (ARI) Extension. |
| 2025-07-01 Operator milestone | Let's Encrypt issues its first certificate for an IP address. Source: We've Issued Our First IP Address Certificate. |
| 2025-08-06 Operator milestone | Let's Encrypt's OCSP service reaches end of life. The largest publicly trusted issuer by volume no longer answers OCSP queries; revocation status for its certificates is distributed through CRLs. Source: OCSP Service Has Reached End of Life. |
| 2025-11-20 Ballot result | Ballot SC-090 begins the phased retirement of the remaining email-based, phone-based, and crossover domain validation methods. Methods that depend on a human reading a message are progressively removed in favour of methods a machine can perform and a third party can observe. Source: Ballot SC-090 - Gradually sunset all remaining email-based, phone-based, and crossover validation methods. |
| 2025-12-02 Operator milestone | Let's Encrypt publishes its roadmap to 45-day certificates. The stages are: an opt-in profile issuing 45-day certificates from 13 May 2026; the default profile moving to 64-day certificates with a 10-day authorization reuse period on 10 February 2027; and the default profile moving to 45-day certificates with a 7-hour authorization reuse period on 16 February 2028. The post recommends ARI, and notes that a client renewing at a hard-coded 60-day interval will no longer be sufficient. Source: Decreasing Certificate Lifetimes to 45 Days. |
| 2026-01-15 Operator milestone | Six-day certificates and IP address certificates become generally available from Let's Encrypt. Short-lived certificates are valid for 160 hours, just over six days, and are requested by selecting the shortlived profile in an ACME client. Source: 6-day and IP Address Certificates are Generally Available. |
| 2026-01-24 Ballot result | Ballot SC-097 sunsets all remaining use of SHA-1 signatures in certificates and CRLs, with a compliance date of 15 September 2026. Twelve years after the original SHA-1 sunset ballot, the exemptions granted to already-existing infrastructure are closed. Source: Ballot SC097 - Sunset all remaining use of SHA-1 signatures in Certificates and CRLs. |
| 2026-02-05 Policy published | Chrome Root Program Policy version 1.8 extends automation requirements from applicants to every trusted CA. From 15 March 2027, every unexpired and unrevoked subordinate CA certificate chaining to a root in the Chrome Root Store must be integrated with an automation solution, the CA owner must disclose at least one automation solution per certificate policy OID in the CCADB, and must demonstrate it with an Automation Test Certificate renewed at least once every 30 calendar days. The policy also limits the number of root certificates per CA owner. Source: Chrome Root Program Policy, Version 1.8. |
| 2026-03-15 Effective date | The first reduction takes effect: the maximum certificate validity period becomes 200 days. On the same date the maximum reuse period for domain name and IP address validation data becomes 200 days, the maximum reuse period for Subject Identity Information becomes 398 days (down from 825), and the definition of a Short-lived Subscriber Certificate tightens from 10 days to 7 days (604,800 seconds). Also effective from this date: DNSSEC validation back to the IANA root trust anchor is mandatory for DNS queries used in domain validation and CAA lookups; certificate authorities must not rely on the IP address validation method in Section 3.2.2.4.8; and certificates must not contain domain names ending in an IP reverse zone suffix. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
| 2026-05-13 Ballot result | Ballot SC-098v2 requires certificate authorities to process the RFC 8657 CAA parameters accounturi and validationmethods, with a compliance date of 15 March 2027. A domain holder will be able to restrict issuance not only to a chosen certificate authority but to a specific account at that authority and to specific validation methods. Source: Ballot SC098v2 - Process RFC 8657 CAA Parameters. |
| 2026-06-29 Policy published | Mozilla publishes Root Store Policy version 3.1, effective 1 July 2026. Where version 3.0 concentrated on revocation and automation, version 3.1 addresses transparency and assurance: clearer expectations for the content and quality of CP/CPS documentation, and Detailed Controls Reports that give more visibility into a CA's controls and testing than a traditional audit opinion. Source: Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1. |
| 2026-09-15 Scheduled | All remaining use of SHA-1 signatures in certificates and CRLs must end. This date has not yet arrived. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
| 2027-03-15 Scheduled | The maximum certificate validity period is scheduled to become 100 days, and the maximum domain and IP address validation data reuse period 100 days. Certificate authorities must also process the RFC 8657 CAA parameters from this date, and must stop relying on validation methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, 3.2.2.5.3, and 3.2.2.5.5. This date has not yet arrived. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
| 2027-03-15 Scheduled | Chrome's automation requirement is scheduled to apply to every subordinate CA certificate in the Chrome Root Store. From this date the Chrome Root Program will begin phasing out PKI hierarchies found issuing certificates under a certificate policy OID that lacks an automation solution attestation in the CCADB, with a phase-out date set 90 calendar days after detection. This date has not yet arrived. Source: Chrome Root Program Policy, Section 1.3.3.1 Automation Support. |
| 2028-03-15 Scheduled | Further domain validation methods are scheduled to be retired. Certificate authorities 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. This date has not yet arrived. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
| 2029-03-15 Scheduled | The maximum certificate validity period is scheduled to become 47 days, and the maximum domain and IP address validation data reuse period 10 days. This is the final step of the schedule introduced by Ballot SC-081v3, and the point at which domain control must in practice be re-proven for almost every issuance. This date has not yet arrived. Source: CA/Browser Forum Baseline Requirements, Section 1.2.2 Relevant Dates. |
There may be slight variations between the date on which a ballot result was published, the adoption date recorded in the Baseline Requirements revision table, and the date from which a requirement applies. Rows labelled "Ballot result" use the publication date of the linked ballot page; rows labelled "Effective date" and "Scheduled" use the compliance dates listed in the Baseline Requirements.
Current Overview of the TLS Certificate Ecosystem
Having followed the chronology, this section summarizes the present state: who sets the rules, what a certificate authority must do to issue, how transparency and revocation work today, where automation is now mandatory rather than merely advisable, and what the remaining schedule requires of operators. Facts in this section were confirmed against their primary sources on 2026-07-31; this is an area where requirements change several times a year, so the version numbers are stated explicitly throughout.Who Decides What: CA/Browser Forum, Root Programs, and the IETF
Three layers of decision-making govern a publicly trusted TLS certificate, and confusing them is the most common source of misunderstanding about "the rules".
| Layer | What it decides | How the decision is published |
|---|---|---|
| CA/Browser Forum | The common floor for publicly trusted TLS certificates: validation methods, certificate profiles, validity periods, revocation, CA operations | Numbered ballots, then a new version of the Baseline Requirements with an adoption date and an effective date. The Requirements carry their own revision table and a "Relevant Dates" table of future compliance dates. |
| Root programs (Chrome, Mozilla, Apple, Microsoft) | Which CA certificates are trusted in their products, and any requirements above the common floor | Each program's own policy document, versioned with a change history. Requirements introduced here sometimes migrate into the Baseline Requirements later. |
| IETF | The formats and protocols: the X.509 profile, CAA, Certificate Transparency, ACME, OCSP and CRLs | RFCs published by the RFC Editor. |
Certification Authorities and Root Programs
A publicly trusted certificate authority operates under the Baseline Requirements plus the policy of every root program it wishes to be included in. The current documents are:- CA/Browser Forum Baseline Requirements — version 2.2.8, dated 16 June 2026 at the time of writing. Section 1.2.1 lists every version with its ballot, adoption date, and effective date; Section 1.2.2 lists future compliance dates.
- Chrome Root Program Policy — version 1.8, last updated 2026-02-05. Chrome has operated its own root store since 2022 and applies its policy through the Chrome Certificate Verifier rather than the host operating system.
- Mozilla Root Store Policy — version 3.1, effective 1 July 2026.
- Apple — publishes its certificate requirements and its Certificate Transparency policy as support documents covering the root CAs preinstalled with its operating systems.
Domain Control Validation Today
Before issuing, a certificate authority must prove that the applicant controls each name in the certificate, and must check CAA records — defined today by RFC 8659, which obsoleted RFC 6844 — to confirm it is authorized to issue at all. What has changed in the last two years is not the idea but the rigour.- Enumerated methods. Since Ballot 169 took effect in 2017, only the methods listed in Section 3.2.2.4 of the Baseline Requirements may be used. Because they are enumerated, they can be retired individually, and several have been: the WHOIS-dependent methods, the IP address method 3.2.2.4.8 (from 2026-03-15), and, on the schedule set by Ballot SC-090, the remaining email-based, phone-based, and crossover methods.
- Multi-Perspective Issuance Corroboration. Mandatory since 2025-03-15. The validation result observed by the primary network perspective must be corroborated from additional perspectives, which raises the cost of attacks that depend on influencing routing or DNS resolution near the certificate authority.
- DNSSEC validation. From 2026-03-15, DNSSEC validation back to the IANA root trust anchor must be performed on DNS queries associated with domain validation and with CAA lookups by the primary network perspective, CAs must not use local policy to disable it, and a DNSSEC validation error must not be treated as permission to issue.
- Pre-issuance linting. Mandatory since 2025-03-15. The to-be-issued certificate is tested for technical conformity before it is signed.
- Reuse periods. Validation is not repeated for every certificate; a completed validation may be reused for a bounded period. That bound is the number that shrinks alongside the certificate lifetime, and it is the one that determines how often the domain owner's DNS or web server must actually respond to a challenge.
Certificate Transparency
Certificate Transparency makes issuance publicly observable. A certificate authority submits a certificate (or a precertificate) to append-only logs and receives Signed Certificate Timestamps, which are delivered to the browser embedded in the certificate, through a TLS extension, or via OCSP stapling.- Specifications. RFC 6962 (2013) defined CT; RFC 9162 (2021) defines version 2.0. The ecosystem is additionally moving to static-ct-api, which serves log data as static tiles instead of through the RFC 6962 API, a change driven by the operating cost of logs as certificate volumes grow.
- Enforcement. Chrome requires CT compliance for all publicly trusted certificates issued after 2018-04-30. The number of SCTs required depends on the certificate's lifetime: under the Chrome CT policy, embedded SCTs must come from two distinct logs for certificates with a lifetime of 180 days or less, and three for longer lifetimes. Apple's CT policy uses the same 180-day threshold, requiring two SCTs at or below it and three above.
- A quiet side effect of shorter lifetimes. Because both policies key the SCT requirement to the 180-day mark, certificates issued under the 200-day cap can still fall on either side of it, while the 100-day and 47-day steps put every certificate in the lower bracket. Shorter certificates therefore carry fewer SCTs, which partially offsets the extra log volume they create.
ACME and Certificate Lifecycle Automation
ACME, standardized as RFC 8555 in 2019, is the protocol by which a client proves domain control and obtains a certificate without human involvement. Around it, three additions matter for the current schedule.- ACME Renewal Information (ARI), RFC 9773, lets the certificate authority tell the client when to renew, replacing a hard-coded interval in the client with a signal from the issuer. This becomes important precisely when lifetimes change: a client that renews every 60 days is correct under a 90-day certificate and broken under a 45-day one.
- Certificate profiles let a subscriber select the kind of certificate they want — for example a short-lived profile — so that an operator can adopt a shorter lifetime deliberately rather than being moved by the issuer's default.
- Automation as a root program requirement. This is the change that most directly answers "when does manual renewal stop working". Under Chrome Root Program Policy version 1.8, from 2027-03-15 every unexpired, unrevoked subordinate CA certificate chaining to a root in the Chrome Root Store must be integrated with an automation solution — ACME or a disclosed non-ACME equivalent — for every certificate profile it offers. The CA owner must disclose the solution in the CCADB and keep an Automation Test Certificate renewed at least every 30 days to demonstrate it. The policy is explicit that this does not prohibit non-automated issuance and does not require website operators to use the automation, but it does mean that from that date an automated path must exist for every publicly trusted certificate type in Chrome.
Revocation: From OCSP to CRLs and Short-Lived Certificates
The revocation model changed direction in 2023 and the consequences are now visible in production.- OCSP is optional; CRLs are required. Since 2024-03-15, a certificate authority may choose not to operate an OCSP responder, but must publish CRLs. The largest publicly trusted issuer by volume ended its OCSP service on 2025-08-06.
- Short-lived certificates need not be revoked. A Short-lived Subscriber Certificate — 10 days or less for certificates issued between 2024-03-15 and 2026-03-15, and 7 days or less for certificates issued from 2026-03-15 — may be revoked by the CA but is not required to be. For everything else, the Requirements set a 24-hour revocation deadline for the most serious reasons (including key compromise and failed domain validation) and five days for the remainder.
- Why this is the real argument for shorter lifetimes. Revocation has never worked reliably at Internet scale: soft-fail checking means a client that cannot reach status information usually proceeds. A certificate that expires in a week bounds the damage without depending on revocation reaching the client at all. That is the trade the schedule makes — less reliance on a mechanism that fails open, in exchange for more frequent issuance.
The Shrinking Certificate Lifetime Schedule
This is the part most operators come for. The numbers below are taken from Sections 4.2.1 and 6.3.2 of the Baseline Requirements and were introduced by Ballot SC-081v3.
| Certificates issued | Maximum validity period | Maximum domain and IP validation data reuse | Short-lived certificate definition | Status |
|---|---|---|---|---|
| Before 2026-03-15 | 398 days | 398 days | 10 days or less | Past |
| 2026-03-15 to 2027-03-15 | 200 days | 200 days | 7 days or less | In force |
| 2027-03-15 to 2029-03-15 | 100 days | 100 days | 7 days or less | Scheduled |
| 2029-03-15 and later | 47 days | 10 days | 7 days or less | Scheduled |
- There is a "SHOULD NOT" one day below every "MUST NOT". The Requirements say certificates issued from 2026-03-15 should not exceed 199 days and must not exceed 200; the same one-day gap applies at 99/100 and 46/47. A day is defined as exactly 86,400 seconds, and any excess counts as an additional day, so the Requirements advise against issuing for the maximum permissible time by default.
- Validation reuse falls faster than validity at the last step. At 2029-03-15 the certificate lifetime becomes 47 days but the domain validation reuse period becomes 10 days. From that point most renewals require a fresh domain control validation, not merely a fresh signature. Any process that depends on a human placing a DNS record or a file on a web server will need to be replaced before then.
- Subject Identity Information follows a different, shorter table. For OV and EV certificates, the reuse period for organization identity data dropped from 825 days to 398 days on 2026-03-15. Organizations that re-verify identity documents on a multi-year cycle are affected even though this is not part of the headline schedule.
- The dates are issuance dates, not expiry dates. A certificate issued on 2027-03-14 may still carry a 200-day lifetime and remain valid well into the 100-day era. The rules bind the moment of issuance.
What This Means for Operators
Nothing in the schedule requires new architecture. It requires that certificate renewal be a process no human has to remember. In practical terms:- Inventory every certificate and record how it is renewed. The certificates that will break are the ones nobody owns: an appliance console, an internal load balancer, a partner's mutual TLS endpoint, a certificate pasted into a configuration file three years ago. Public Certificate Transparency logs are a useful cross-check against your own inventory, because they show what has actually been issued for your domains.
- Replace fixed renewal intervals with ARI. A client that renews at a hard-coded interval is correct only until the issuer changes its lifetime. If a client does not support ARI, renew at roughly two-thirds of the way through the current certificate's lifetime rather than at a fixed number of days.
- Check the validation path, not just the issuance path. As reuse periods shrink toward 10 days, the DNS or HTTP challenge mechanism runs far more often. Delegating the challenge to a stable, automatable location — for example a dedicated DNS zone or a CNAME to a validation-specific record — matters more than it did when validation was reused for a year.
- Publish CAA records, and plan for the parameters. CAA checking has been mandatory since 2017. From 2027-03-15, CAs must also process the RFC 8657
accounturiandvalidationmethodsparameters, which allow issuance to be restricted to a particular account and a particular validation method. - Monitor expiry independently of the renewal process. Automation that fails silently is worse than a calendar reminder. Alerting should be driven by the certificate actually being served, not by the job that was supposed to renew it.
- Do not rely on revocation as a containment plan. With OCSP optional and soft-fail behaviour widespread, the practical containment mechanism for a compromised key is a short remaining lifetime plus the ability to reissue and redeploy quickly. That ability is worth testing.
Where This Is Heading
The published direction of travel, as stated by the Chrome Root Program in its Moving Forward, Together document, covers several areas under exploration. These are explicitly described as proposals rather than requirements, with no implementation timelines unless stated in the policy itself or in a CA/Browser Forum ballot. Three are worth knowing about because they shape what the next decade of this timeline is likely to contain.- Merkle Tree Certificates. An approach in which a CA signs a single tree head covering many certificates, and the artifact sent to the browser is a compact inclusion proof rather than a chain of signatures. The stated motivation is post-quantum signature sizes, which would otherwise make a straightforward migration prohibitively large on the wire. Transparency becomes intrinsic to issuance rather than an add-on.
- More ephemeral issuing infrastructure. Bounded lifetimes for subordinate CA certificates, faster issuer key rotation, and randomized issuance, all aimed at reducing how many live certificates any single issuing key is responsible for.
- Verifiable and reproducible domain control validation. Making the proof of domain control publicly and persistently verifiable, so that a later bug in a CA's validation logic does not automatically require mass revocation of everything it issued.
Frequently Asked Questions about TLS Certificate Ecosystem History
How long can a publicly trusted TLS certificate be valid in 2026?
Certificates issued on or after 2026-03-15 must not have a validity period greater than 200 days, and the Baseline Requirements state that they should not exceed 199 days. Certificates issued before that date were capped at 398 days. The limit applies at the moment of issuance, so a certificate issued before 2026-03-15 with a 398-day lifetime remains valid for its full term.When does the maximum certificate validity period drop to 47 days?
On 2029-03-15. The schedule introduced by CA/Browser Forum Ballot SC-081v3 has four steps: 398 days before 2026-03-15, 200 days from 2026-03-15, 100 days from 2027-03-15, and 47 days from 2029-03-15. Only the first two are in force at the time of writing; the 100-day and 47-day steps are scheduled.What happens to domain validation reuse periods?
They shrink on the same dates as the certificate lifetime, but the final step is much sharper. The maximum reuse period for domain name and IP address validation data was 398 days, became 200 days on 2026-03-15, becomes 100 days on 2027-03-15, and becomes 10 days on 2029-03-15. Separately, the reuse period for Subject Identity Information used in OV and EV certificates fell from 825 days to 398 days on 2026-03-15.When did OCSP stop being required?
On 2024-03-15, when Ballot SC63 took effect. That ballot made OCSP optional for certificate authorities, made CRL publication mandatory, and defined the Short-lived Subscriber Certificate. Individual certificate authorities have since retired their OCSP services; Let's Encrypt's OCSP service reached end of life on 2025-08-06.What is a short-lived certificate, and does it have to be revoked?
Under the Baseline Requirements, a Short-lived Subscriber Certificate is one with a validity period of 10 days or less if issued between 2024-03-15 and 2026-03-15, or 7 days or less if issued on or after 2026-03-15. A certificate authority may support revocation of such certificates but is not required to, which is the main operational incentive to adopt them. Let's Encrypt made six-day certificates, valid for 160 hours, generally available on 2026-01-15.When did Certificate Transparency become mandatory in Chrome?
Chrome requires all publicly trusted TLS certificates issued after 2018-04-30 to be CT compliant in order to validate. Certificate Transparency itself was specified in RFC 6962 in June 2013, and version 2.0 was published as RFC 9162 in December 2021.When was ACME standardized, and when does automation become mandatory?
ACME was published as RFC 8555 in March 2019, and the ACME Renewal Information extension as RFC 9773 in June 2025. Automation becomes mandatory on the certificate authority side under Chrome Root Program Policy version 1.8: from 2027-03-15, every unexpired and unrevoked subordinate CA certificate chaining to a root in the Chrome Root Store must be integrated with an automation solution, disclosed in the CCADB, and demonstrated with an Automation Test Certificate renewed at least every 30 days. The policy does not require website operators to use automation, but from that date an automated issuance path must exist for every publicly trusted certificate profile in Chrome.Why is the industry shortening certificate lifetimes?
The reasons given in the primary sources are consistent: revocation is unreliable in practice because clients that cannot reach status information generally proceed anyway, so a shorter lifetime bounds the damage from a compromised key or a mis-issued certificate without depending on revocation reaching the client. Shorter lifetimes also force certificate management to be automated, which in turn makes it feasible to replace certificates quickly when a certificate authority has to respond to an incident. Let's Encrypt set out this argument for 90-day certificates in 2015; the CA/Browser Forum adopted a schedule based on the same reasoning in 2025.Summary
In this article I built a historical timeline of the publicly trusted TLS certificate ecosystem and summarized its current state: who sets the rules, how certificates are validated and logged, how revocation now works, and what the scheduled reductions in certificate lifetime require of operators.The timeline shows three phases. From 1999 to 2011 the ecosystem ran on IETF formats with no common floor for the authorities that used them, and a single mis-issuance episode could only be answered by removing a root. From 2011 to 2019 the floor was built: the Baseline Requirements, mandatory CAA checking, enumerated validation methods, Certificate Transparency as a condition of trust in Chrome, and ACME as an IETF standard. From 2020 onward the ecosystem began to spend the agility that automation bought it — 398 days, then OCSP made optional and short-lived certificates defined, then multi-perspective validation and pre-issuance linting, and finally the schedule that runs 200 days, 100 days, 47 days.
What makes this history unusually legible is that almost every step is a dated, published decision with a named ballot or policy version behind it. A reduction that failed twice as a standalone ballot arrived through a root program and then returned to the Forum unanimously. That is the thread worth remembering: the disagreement was never about whether certificates should live shorter lives, only about how fast the ecosystem could automate enough to survive it.
For an operator, the schedule reduces to one requirement. By 2029-03-15, domain control will have to be re-proven roughly every ten days and certificates replaced roughly every six weeks. Any renewal process that still depends on a person is on a countdown, and the countdown is public.
This timeline will be updated as the TLS certificate ecosystem continues to evolve.
In addition, there are related history-and-timeline articles on this site, so please have a look if you are interested.
AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
Major Security Vulnerabilities History and Timeline - Disclosure, Impact, and the Response Practices They Changed
Post-Quantum Cryptography Standardization Timeline and Migration on AWS - From Algorithm Selection to Service Support
Tool Use and Agent Protocol History and Timeline - Function Calling, MCP, and A2A
AWS History and Timeline regarding AWS KMS - Overview, Functions, Features, Summary of Updates, and Introduction to KMS
AWS History and Timeline regarding Elastic Load Balancing - Overview, Load Balancer Types, Features, Summary of Updates, and Introduction to ELB
References:
CA/Browser Forum Baseline Requirements
Ballot SC081v3 - Introduce Schedule of Reducing Validity and Data Reuse Periods
Chrome Root Program Policy
Mozilla Root Store Policy
Apple: About upcoming limits on trusted certificates
Certificate Transparency in Chrome
RFC 8555 - Automatic Certificate Management Environment (ACME)
RFC 9773 - ACME Renewal Information (ARI) Extension
RFC 8659 - DNS Certification Authority Authorization (CAA) Resource Record
RFC 8657 - CAA Record Extensions for Account URI and ACME Method Binding
Major Security Vulnerabilities History and Timeline
HTTP Security Headers Complete Reference
Cryptography Glossary for Engineers
Indie Developer Guide from Domain Setup to Deploy
SSL/TLS Certificate Decoder (Tool)
References:
Tech Blog with curated related content
Written by Hidekazu Konishi