SHA-1, a cryptographic hash algorithm used for years in certificate signatures, was formally deprecated across major browsers between 2015 and 2017 — a process notable for how long the industry knew about SHA-1's theoretical weaknesses before actually acting, and how carefully staged the eventual removal was.
The theoretical weakness, known for over a decade
Cryptographers had identified theoretical weaknesses in SHA-1's collision resistance (the difficulty of finding two different inputs that produce the same hash output) as early as 2005 — over a decade before browsers actually stopped trusting SHA-1-signed certificates. For most of that decade, the weakness remained theoretical: computationally expensive enough that a practical, real-world attack wasn't yet demonstrated.
Why the industry moved anyway, ahead of a practical attack
Rather than waiting for an actual demonstrated attack (the pattern that had driven urgency around most other TLS vulnerabilities), browser vendors and CAs made the unusual choice to proactively deprecate SHA-1 based on the trajectory of computing power and cryptanalysis research — reasoning that a practical collision attack was a matter of when, not if, and that certificate signatures (which can remain in use for a year or more) needed a longer lead time than a typical emergency patch.
SHAttered: the practical demonstration, right on schedule
In February 2017, researchers from Google and CWI Amsterdam published SHAttered, the first practical SHA-1 collision — produced using significant computing resources, but demonstrating conclusively that the theoretical weakness was now practically exploitable. Notably, this arrived after major browsers had already substantially completed their SHA-1 deprecation for certificate signatures, validating the industry's earlier, proactive decision to move ahead of an actual attack rather than waiting for one.
The staged deprecation timeline
CAs stopped issuing new SHA-1-signed certificates around 2016, well before browsers began actively rejecting existing SHA-1 certificates — giving the industry time to naturally cycle out SHA-1 certificates through normal expiry and renewal before browsers needed to force the issue for any certificates that hadn't yet been replaced.
The broader lesson: acting ahead of demonstrated exploitation
SHA-1's deprecation is frequently cited as a rare example of the security industry successfully acting on a theoretical weakness before practical exploitation, in contrast to the more common pattern (seen with most other named TLS vulnerabilities) of reacting to an already-demonstrated attack. It's held up as a model for how cryptographic algorithm transitions ideally should work — informed by research trajectory rather than crisis response.
The economics of a SHA-1 collision, tracked over time
Part of what made the industry's proactive stance credible was that cryptographers weren't just asserting SHA-1 was theoretically weak — they were tracking the estimated computational cost of an actual collision attack as it dropped year over year, driven by both algorithmic refinements to the attack itself and the falling cost of large-scale computing (including, notably, cloud computing platforms that made renting massive parallel compute capacity newly affordable). By the early 2010s, estimates had brought a practical SHA-1 collision from something requiring resources only a well-funded intelligence agency might plausibly have, down toward a cost increasingly within reach of a well-resourced private research team or corporation — which is roughly the estimated cost class SHAttered's authors ultimately worked within.
How SHAttered was actually achieved
The 2017 SHAttered collision required an enormous amount of computation — reported at the time as roughly equivalent to 6,500 years of single-CPU computation, or around 110 years of single-GPU computation, compressed into a much shorter real-world timeframe through massively parallel processing across many machines. The researchers produced two distinct PDF files that hash to the identical SHA-1 value despite having completely different visible content — a vivid, easily demonstrated proof that the collision resistance property SHA-1 was supposed to guarantee had genuinely broken down in practice, not just in theory.
Why certificate signatures specifically were the priority, not all SHA-1 uses
It's worth noting that the browser-driven SHA-1 deprecation specifically targeted its use in certificate signatures — the deprecation timeline didn't necessarily mean SHA-1 was instantly removed from every context where it had historically been used (some non-security-critical checksums, for instance, continued using it for longer). Certificate signatures were prioritized because a forged signature there has an unusually severe consequence: it could let an attacker forge a certificate that impersonates any domain, trusted by any browser, the exact worst-case scenario a certificate's signature is supposed to make impossible. Other, lower-stakes uses of SHA-1 saw a more gradual, less urgently enforced transition.
How site owners experienced the transition
For most site owners, the actual experience of the SHA-1 deprecation was fairly uneventful — CAs had already shifted default issuance to SHA-256 well before browsers began actively rejecting SHA-1 certificates, meaning any certificate issued reasonably close to the transition period was already unaffected. The main group who did encounter friction were organizations running older, longer-lived certificates issued before CAs made the switch, or running older server software that hadn't been updated to properly support SHA-256 signature verification — a reminder that even a well-planned, gradual industry transition still leaves a tail of affected systems that simply hadn't been updated in step with the broader ecosystem.
What replaced SHA-1, and what might eventually replace that
SHA-256 (part of the SHA-2 family) became the standard replacement for certificate signatures, and remains the dominant choice today — though the SHA-3 family, standardized separately using a fundamentally different internal design (specifically chosen to not share SHA-1 and SHA-2's structural approach, reducing the risk that a future weakness affecting one family would also affect the other), exists as a further option for cases wanting cryptographic diversity. Given how the SHA-1 transition unfolded — years of advance warning based on trajectory analysis rather than waiting for practical exploitation — it's widely seen within the cryptography community as the template the industry would ideally follow again whenever SHA-256 itself eventually needs a similar, proactively managed transition.
How to check whether this still affects anything you manage
For any current, actively used certificate, SHA-1 signature issues should be entirely a thing of the past — no publicly trusted CA has issued SHA-1-signed certificates in years, and any that remained have long since expired given standard certificate validity periods. Where this history can still resurface in practice is with very old, long-forgotten internal or legacy systems — an old internal tool, an embedded device, or an ancient self-signed certificate that was set up years ago and never revisited. Running openssl x509 -in yourcert.pem -text -noout and checking the "Signature Algorithm" field directly is a quick way to confirm any certificate you're responsible for, however old, isn't still relying on SHA-1.
Why the deprecation timeline still gets cited as a model years later
Security and cryptography conference talks, industry postmortems, and academic papers on responsible vulnerability management continue to reference the SHA-1 deprecation timeline specifically because so few comparable transitions have been handled this proactively. Most of the other named vulnerabilities covered throughout this history section — Heartbleed, POODLE, the various CBC-mode attacks — involved the industry reacting after a practical exploit was already demonstrated or discovered in the wild. SHA-1's phase-out remains one of the clearest counter-examples: years of coordinated advance planning, informed by tracking research trajectory rather than waiting for an actual attack, resulting in the practical demonstration (SHAttered) arriving after the migration was already substantially complete rather than triggering it.
SHA-1 outside of TLS certificates
It's worth noting SHA-1 has had a longer, messier deprecation story in some other contexts beyond certificate signatures specifically — version control systems, older digital signature standards, and some legacy authentication protocols retained SHA-1 usage for longer, each with their own separate migration timeline and pressures. The certificate-signature case discussed here was simply the first and most urgently prioritized, given the severity of what a forged certificate signature could enable.
A related transition worth knowing about
MD5, SHA-1's predecessor, went through a broadly similar though less coordinated deprecation arc roughly a decade earlier, discussed in more detail in our companion article on the Flame malware's MD5 certificate forgery — together the two form a useful before-and-after comparison of how the industry's response to aging hash algorithms matured over time.
The specific role of academic cryptanalysis competitions in tracking SHA-1's decline
Academic cryptography conferences and dedicated cryptanalysis competitions played a meaningful role in publicly tracking SHA-1's declining security margin over the 2000s and early 2010s, with successive papers incrementally reducing the estimated cost of a practical collision — this steady, published research trail is precisely what gave the industry the confidence to plan a proactive migration timeline years ahead of an actual demonstrated attack.
The specific role of academic cryptanalysis competitions in tracking SHA-1's decline
Academic cryptography conferences and dedicated cryptanalysis research played a meaningful role in publicly tracking SHA-1's declining security margin over the 2000s and early 2010s, with successive papers incrementally reducing the estimated cost of a practical collision — this steady, published research trail is precisely what gave the industry the confidence to plan a proactive migration timeline years ahead of an actual demonstrated attack.