> A dated timeline of PKI and TLS: public-key papers, SSL and TLS versions, CA breaches, Certificate Transparency, ACME, shorter lifetimes and post-quantum. Source: https://pkizerotohero.com/handbook/timeline/ · Last reviewed: 2026-10-20 Appendix # Timeline: how PKI got here **In one sentence:** From the first public-key papers in the 1970s to ever-shorter certificate lifetimes and post-quantum key exchange: the milestones and incidents that shaped how certificates work today. ## Who is this for - [Expert](https://pkizerotohero.com/start/#expert) - [Leader](https://pkizerotohero.com/start/#leader) - [Teacher](https://pkizerotohero.com/start/#teacher) - [Beginner](https://pkizerotohero.com/start/#beginner) - [Developer](https://pkizerotohero.com/start/#developer) - [IT ops](https://pkizerotohero.com/start/#itops) Level: **Beginner** Every date on this page comes from the site’s checked list of facts, with a primary source behind each one. Entries describe incidents only at the level of “what went wrong, how it was noticed and what changed”. For the stories behind the incidents, read [Famous failures](https://pkizerotohero.com/handbook/famous-failures/). ## The foundations: 1970s to 1990s - **November 1976:** "New Directions in Cryptography" is published, introducing public-key key exchange. Two parties can agree a secret in public, and the idea of a public key is born. See [key exchange](https://pkizerotohero.com/handbook/key-exchange/). - **February 1978:** the RSA paper, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", is published. The first practical algorithm for both public-key encryption and signatures. See [key pairs](https://pkizerotohero.com/handbook/key-pairs/). - **November 1988:** the first edition of X.509, "The Directory: Authentication framework", is published. The certificate format that, after several revisions, still carries every HTTPS certificate. See [X.509 certificates](https://pkizerotohero.com/handbook/x509-certificates/). - **November 1996:** SSL 3.0, the direct ancestor of TLS, is specified. TLS 1.0 was built directly on it. - **January 1999:** TLS 1.0 is published as RFC 2246, the IETF’s standardised successor to SSL. - **January 1999:** RFC 2459 profiles X.509 certificates and CRLs for the internet for the first time. - **June 1999:** RFC 2560 defines OCSP, the online way to ask whether a certificate was revoked. See [revocation](https://pkizerotohero.com/handbook/revocation/). ## Building the web PKI: 2000s - **2005:** the CA/Browser Forum is formed. CAs and browser makers now write shared rules together. - **April 2006:** TLS 1.1 is published as RFC 4346. - **June 2007:** the CA/Browser Forum adopts version 1.0 of the EV Guidelines. See [domain validation](https://pkizerotohero.com/handbook/domain-validation/). - **May 2008:** RFC 5280 becomes the internet profile of X.509, including the path validation algorithm. See [certificate chains](https://pkizerotohero.com/handbook/certificate-chains/). - **August 2008:** TLS 1.2 is published as RFC 5246. ## Trust breaks, transparency arrives: 2010s - **2011:** DigiNotar was breached, issued fraudulent certificates and was removed from browser trust stores. The incident helped motivate Certificate Transparency. See [famous failures](https://pkizerotohero.com/handbook/famous-failures/). - **1 July 2012:** the CA/Browser Forum Baseline Requirements take effect. Every publicly trusted TLS CA now follows one common rulebook. - **June 2013:** RFC 6962 defines Certificate Transparency: public logs of every certificate. See [Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/). - **7 April 2014:** the Heartbleed bug in OpenSSL (CVE-2014-0160) is disclosed. Servers had to assume their private keys had leaked, and mass reissuance and revocation followed. - **23 July 2014:** the EU adopts the eIDAS Regulation on electronic identification and trust services. Electronic signatures gain a common legal framework across the EU. See [code and document signing](https://pkizerotohero.com/handbook/code-signing/). - **September 2015:** Let's Encrypt issues its first certificate. Free, automated certificates help make HTTPS the norm across the web. See [ACME](https://pkizerotohero.com/handbook/acme/). - **February 2017:** the first public SHA-1 collision. SHA-1 is broken in practice, after publicly trusted certificates had already moved to SHA-256. See [hashes](https://pkizerotohero.com/handbook/hashes/). - **Chrome 58 (April 2017):** Chrome ignores the Common Name and requires the hostname in the Subject Alternative Name. The Common Name stops counting in browsers. See [names and key usage](https://pkizerotohero.com/handbook/names-and-key-usage/). - **8 September 2017:** CAs must check CAA records before issuing. Domain owners can now limit which CAs may issue for them. - **April 2018:** Chrome requires Certificate Transparency for publicly trusted TLS certificates. - **2018:** Chrome and Firefox stopped trusting TLS certificates from Symantec's old CA infrastructure. Even one of the largest CAs can be distrusted for repeated failures. - **August 2018:** TLS 1.3 is published as RFC 8446: faster handshakes, forward secrecy for every full handshake, and the certificate key only signs. See [the TLS 1.3 handshake](https://pkizerotohero.com/handbook/tls-handshake/). - **March 2019:** ACME is standardised as RFC 8555. ## Shorter lives and stricter rules: 2020 to 2025 - **1 September 2020:** the maximum lifetime of a publicly trusted TLS certificate drops to 398 days. - **March 2021:** RFC 8996 formally retires TLS 1.0 and 1.1. - **30 September 2021:** DST Root CA X3, the older root that had cross-signed Let's Encrypt, expired, so devices that did not trust ISRG Root X1 began rejecting Let's Encrypt certificates. A lesson in how cross-signing and root expiry play out on old devices. See [cross-signing](https://pkizerotohero.com/handbook/cross-signing/). - **December 2021:** RFC 9162 defines Certificate Transparency version 2. - **September 2022:** Google launches the Chrome Root Program, which decides which certificates Chrome trusts by default. See [trust stores](https://pkizerotohero.com/handbook/trust-stores/). - **15 December 2022 (NIST announcement):** NIST announces that SHA-1 should be phased out by 31 December 2030. - **1 June 2023:** the private keys of publicly trusted code signing certificates must be generated, stored and used in a hardware crypto module. See [code signing](https://pkizerotohero.com/handbook/code-signing/). - **1 September 2023:** the CA/Browser Forum S/MIME Baseline Requirements apply to every publicly trusted S/MIME certificate. - **November 2023 (replaces RFC 6125):** RFC 9525 updates the rules for matching hostnames against certificates. - **15 March 2024:** OCSP became optional and CRLs became mandatory for publicly trusted TLS certificates. See [revocation](https://pkizerotohero.com/handbook/revocation/). - **20 May 2024:** Regulation (EU) 2024/1183 (eIDAS 2.0) enters into force, updating eIDAS and adding the European Digital Identity Wallet. - **13 August 2024:** NIST publishes FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), the first post-quantum standards. See [post-quantum cryptography](https://pkizerotohero.com/handbook/post-quantum/). - **late 2024 in Chrome 131 and Firefox 132:** X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems. - **12 November 2024:** Chrome stopped trusting new Entrust TLS certificates (those first logged in Certificate Transparency after 11 November 2024). - **NIST IR 8547 (initial public draft, November 2024):** NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035. - **11 March 2025:** HQC is selected for standardisation by NIST, as a second post-quantum key-encapsulation mechanism. - **Firefox 137 (April 2025):** Firefox on desktop checks revocation with CRLite, a compact list of revoked certificates that it downloads in the background. - **11 April 2025:** CA/Browser Forum Ballot SC-081v3 is adopted, setting the schedule that shortens TLS certificate lifetimes step by step to 47 days. See [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/). - **23 June 2025:** the EU’s coordinated post-quantum roadmap says EU member states should start the transition by the end of 2026, finish it for high-risk use cases by the end of 2030 and complete as much as feasible by 2035. - **6 August 2025:** Let's Encrypt has shut down its OCSP service. ## Now and next: 2026 onwards - **15 January 2026:** Let’s Encrypt offers six-day certificates to everyone who opts in. - **11 February 2026 for the default profile, and 8 July 2026 for the last opt-in profile:** Let's Encrypt certificates no longer include the TLS client authentication purpose. See [mutual TLS](https://pkizerotohero.com/handbook/mutual-tls/). - **27 February 2026:** Chrome plans a separate quantum-resistant root store built on Merkle Tree Certificates, and has no immediate plan to add post-quantum X.509 certificates to the Chrome Root Store. - **1 March 2026:** the maximum lifetime of a public code signing certificate becomes 460 days. - **15 March 2026:** the maximum lifetime of a publicly trusted TLS certificate becomes 200 days. - **15 June 2026:** Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication. - **July 2026 (replaces RFC 8446):** TLS 1.3 is republished as RFC 9846. - **August 2026:** RFC 10024 standardises the hybrid post-quantum key exchange groups that browsers use. - **15 September 2026:** publicly trusted CAs must stop all remaining use of SHA-1 in TLS certificates and CRLs. - **15 March 2027:** the maximum TLS certificate lifetime becomes 100 days. - **15 March 2027:** TLS certificates that chain to the Chrome Root Store must list only the TLS server authentication purpose. - **15 March 2029:** the maximum TLS certificate lifetime becomes 47 days. Automation stops being optional. Planning dates further out, for post-quantum migration, are on the [post-quantum page](https://pkizerotohero.com/handbook/post-quantum/#what-are-the-deadlines). For the latest changes, see [What’s changing in PKI](https://pkizerotohero.com/changes/). **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/handbook/timeline/). Last reviewed 20 October 2026Edition 0.9 ## Keep going ### Topics - [Revocation and transparency](https://pkizerotohero.com/topics/revocation-and-transparency/)