NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: SHA-1 Cert Fix

Problem

Chrome refuses the page with NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM and a “Your connection is not private” screen. The certificate isn’t expired, the name matches, the chain resolves — so the usual suspects are all innocent. This error is about how a certificate in the chain was signed, not who it was issued to or when. Somewhere in the chain a certificate is signed with SHA-1, and Chrome stopped trusting SHA-1 signatures years ago.

The reason is not pedantry. SHA-1 is a broken hash function. Public certificate authorities stopped issuing SHA-1 certificates by January 1, 2016, and Chrome fully distrusted SHA-1 certificates chaining to public roots in Chrome 56, released in late January 2017. Weeks later, in February 2017, Google and CWI Amsterdam published SHAttered — the first practical SHA-1 collision — which turned “theoretically weak” into “demonstrably forgeable.” A signature is only as trustworthy as the hash under it, and SHA-1’s is no longer trustworthy at all. So Chrome doesn’t warn; it refuses.

Symptoms

• Chrome (and Chromium browsers) show NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM; there’s usually no “proceed anyway” link because the algorithm, not just the identity, is the problem.
• The certificate is otherwise valid — not expired, correct hostname, complete chain — which is what makes this confusing.
• It appears most on internal tools, old network appliances, IPMI/BMC management consoles, routers, and self-hosted gear — anything with a certificate that predates 2016 or comes from a private CA nobody modernized.
• The leaf certificate may itself be SHA-256, yet the error persists — the tell that the weak signature is on an intermediate, not the cert you’re looking at.

Top 3 Causes

1. A SHA-1 intermediate in an otherwise-modern chain - Your leaf is SHA-256, but the intermediate certificate your server sends alongside it is an old SHA-1 one the CA long since replaced. Chrome checks every signature in the chain except the root, hits the SHA-1 intermediate, and rejects the whole thing. This is the most common real-world cause in 2026, because the leaf looks perfect and everyone stares at it instead of the chain.
2. A private or internal CA still minting SHA-1 certificates - Corporate PKI, a homelab CA, or an appliance vendor’s baked-in CA that was configured before SHA-256 was the default and never changed. Public CAs can’t issue SHA-1 anymore, so in practice a SHA-1 leaf almost always means a private issuer. The fix isn’t buying a cert — it’s regenerating the CA and everything under it with SHA-256.
3. An old self-signed certificate or legacy device - Routers, storage arrays, printers, hypervisor management interfaces, and other long-lived hardware often ship a self-signed SHA-1 certificate generated years ago and never rotated. The device works; only the browser’s tightened rules changed underneath it. The certificate has to be regenerated on the device with a modern algorithm.

Diagnose with DechoNet

• SSL Check inspects the full certificate chain the server presents and reports the signature algorithm of each certificate in it. This is the one thing you need: it tells you which cert is SHA-1 — the leaf or an intermediate — and that single fact decides whether you reissue the certificate or reinstall the intermediate bundle.
• DNS Check confirms which host you’re actually hitting. On internal networks a hostname sometimes resolves to an old appliance still serving the stale certificate while you assume you’re on the new endpoint — rule that out before you go editing the wrong box.

Resolution Checklist

• Identify which certificate is SHA-1. Run an SSL check and read the signature algorithm on each cert in the chain. Leaf → reissue the certificate. Intermediate → your chain bundle is stale.
• If it’s the intermediate, download the current intermediate bundle from your CA and reinstall it on the server. Your leaf is fine; the server is just stapling an obsolete link into the chain. No reissue needed.
• If it’s a public-CA leaf that’s somehow SHA-1, request a free reissue — every public CA issues SHA-256 by default now, and reissues are routine at no cost.
• If it’s a private/internal CA, the SHA-1 is baked into how the CA signs. Regenerate the issuing CA (or reconfigure it to sign with SHA-256) and reissue the certificates under it. Redistribute the new CA to clients if it’s in their trust stores.
• For a legacy device or appliance, regenerate its self-signed certificate with SHA-256 in the device’s own management UI, or replace it with a cert from a modern CA if the device allows importing one.
• Retest with an SSL check. Every certificate in the chain except the root should read SHA-256 (or stronger). A SHA-1 root is expected and fine — its signature is never validated.

When to Escalate

• If the SSL check shows a SHA-1 intermediate but reinstalling the current bundle doesn’t clear it, a proxy or load balancer in front of the origin may be terminating TLS and injecting its own stale chain. Fix the chain on whichever hop actually presents the certificate to the browser — frequently not the box you first edited.
• If a vendor appliance offers no way to regenerate its certificate with SHA-256, that’s a support ticket to the vendor, not a config you can win. A device that can only sign SHA-1 in 2026 is end-of-life for browser access, and the honest answer is to put a modern reverse proxy in front of it rather than click past a broken signature.
• If this appeared suddenly on a cert that “worked yesterday,” nothing about the certificate changed — the browser did. A Chrome update tightening algorithm enforcement, or a machine that finally got current, will surface a SHA-1 chain that was quietly failing checks all along. The certificate was always the problem; the browser just stopped tolerating it.