SHA-1 Is Finally Being Removed from the Last Corners of PKI

On January 24, 2026, the CA/Browser Forum approved a ballot to fully sunset the remaining uses of SHA-1 signatures within the public certificate ecosystem. The change targets edge cases that survived long after SHA-1 was deprecated from regular TLS certificates.

This is not a reaction to a new cryptographic break. SHA-1 has been considered unsuitable for years. What changed is tolerance. The industry is removing the last exceptions that allowed outdated signatures to exist quietly inside otherwise modern trust chains.

What Was Still Using SHA-1 — and Why It Matters

For most website owners, SHA-1 has been “gone” for a long time. Browsers stopped trusting SHA-1-signed TLS certificates years ago, and leaf certificates today use stronger hash algorithms by default.

But deeper in the hierarchy, some older components remained:

• Subordinate CAs created years ago and never reissued.
• CRLs (Certificate Revocation Lists) signed once and reused for long periods.
• Long-lived infrastructure that rarely changed because it was invisible to end users

These elements didn’t trigger browser warnings, but they created inconsistency. Mixed cryptographic standards make auditing harder, increase exception handling, and complicate incident response when something goes wrong.

The new ballot removes that inconsistency.

Why the Industry Is Cleaning This Up Now

The push is about uniform trust, not emergency risk mitigation.

Several forces converged:

• Root programs seek a predictable, consistent cryptographic standard.
• Audits increasingly flag old exceptions that no longer meet current rules.
• Incident handling becomes slower when legacy components behave differently.
• Long-term trust can’t rely on algorithms that are already retired elsewhere.

In short. SHA-1 wasn’t breaking the system, but it no longer fit inside it.

What Changes for Website Owners and IT Teams

Most organizations won’t need to take direct action. However, indirect effects are worth understanding:

• Intermediate chains may change as CAs reissue or rotate older components.
• Cached certificate chains on servers, CDNs, or appliances may surface outdated intermediates.
• Hard-coded chains increase the risk of unexpected validation failures after updates.

This is another reminder that certificate trust is not static. Even if your own certificate remains valid, the surrounding ecosystem continues to evolve.

How SSL Dragon Customers Should Prepare

For teams managing production websites or applications, the preparation is practical rather than urgent:

• Avoid hard-coding intermediate certificates unless absolutely required.
• Periodically refresh certificate chains on servers and load balancers.
• Review older infrastructure where certificates were installed once and forgotten.
• Opt for CAs that actively modernize their hierarchies and communicate changes promptly.

These steps reduce the surprise validation issues when industry cleanups happen in the background.

Note: As part of this transition, SSL Dragon’s CSR Generator has been updated to default to SHA-2 for all new certificate requests.

SSL Dragon’s Take

SHA-1’s final removal isn’t about discovering a new weakness, but closing the gap between how trust looks on the surface and how it behaves underneath.

Public trust works best when every layer follows the same rules. Allowing outdated signatures to persist, even in places most users never see, adds complexity without benefit. Cleaning that up makes certificate chains easier to recover.

For our customers, this change reinforces an important assertion: certificates aren’t “set and forget.” Trust evolves, standards tighten, and infrastructure needs occasional cleanup to stay aligned. 

Use SSL Dragon’s SSL Checker to scan your full certificate chain and confirm there are no legacy SHA-1 signatures hiding in intermediates or revocation data.

Source: CA/Browser Forum – Ballot SC097: Sunset all remaining use of SHA-1 signatures in Certificates and CRLs