Timeline: how PKI got here

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.

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.
• 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.
• 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.
• 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.

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.
• May 2008: RFC 5280 becomes the internet profile of X.509, including the path validation algorithm. See 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.
• 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.
• 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.
• September 2015: Let's Encrypt issues its first certificate. Free, automated certificates help make HTTPS the norm across the web. See 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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. For the latest changes, see What’s changing in PKI.