NET::ERR_CERT_WEAK_KEY in Chrome: Fix

Problem

Chrome refuses to connect and shows NET::ERR_CERT_WEAK_KEY, with no “proceed anyway” option. The certificate isn’t expired and the name matches — the problem is the cryptographic key inside it. A certificate somewhere in the chain uses an RSA key Chrome considers too small to trust.

Symptoms

• Chrome shows NET::ERR_CERT_WEAK_KEY as a full-page interstitial with no bypass link.
• The certificate is otherwise fine — not expired, right hostname, chain present.
• The site is usually an internal or legacy endpoint: a router or firewall admin page, a server’s out-of-band management console (iLO/iDRAC), an old NAS, an IoT device, or a service behind a private CA.
• It may load in older browsers or even in Firefox (which draws its line differently), making it look inconsistent.

What This Error Actually Means

Every TLS certificate carries a public key, and the strength of that key is what stands between an attacker and impersonating the server. RSA keys get their strength from size. A 512-bit key was factorable years ago; 1024-bit keys are within reach of well-resourced attackers and have been considered unfit for long-lived use for over a decade. Chrome encodes a hard floor: an RSA key below 1024 bits is rejected outright with ERR_CERT_WEAK_KEY (the Chromium change enforcing this is tracked as “Enforce a minimum RSA key size of 1024”). It is not a warning you can wave past — it’s a refusal.

Two facts make this error genuinely useful for diagnosis rather than just annoying.

First, no public Certificate Authority can be the source. The CA/Browser Forum Baseline Requirements forbade public CAs from issuing certificates with RSA keys under 2048 bits, with anything valid past 2013-12-31 out of bounds. So a certificate weak enough to trip ERR_CERT_WEAK_KEY did not come from Let’s Encrypt, DigiCert, or any public CA — it came from a private/internal CA, a self-signed appliance, an embedded device that generated its own key, or an ancient certificate minted before the rules tightened. That immediately narrows where to look.

Second, Chrome checks the whole chain, not just the leaf. A perfectly modern 2048-bit leaf certificate can still trigger the error if it chains through an old 1024-bit intermediate. Root certificates are exempt — they’re self-signed trust anchors and aren’t validated the same way — but every certificate below the root has to clear the bar. A weak intermediate is a common, easy-to-miss cause: the server certificate looks fine on its own, and the weakness is one level up.

Top 3 Causes

1. A legacy appliance or device with a small self-signed key - Routers, firewalls, management consoles, older NAS units, and IoT devices often ship with a self-signed certificate generated from a 512- or 1024-bit RSA key baked in at the factory. It worked for years; a Chrome update tightened the floor and now the admin page is unreachable. The fix is to regenerate the device’s certificate with a modern key, if the firmware allows it.
2. A weak intermediate in an otherwise fine chain - The leaf certificate is a healthy 2048-bit key, but it was issued by an internal CA whose intermediate still uses a 1024-bit key from years ago. Chrome validates the whole path and rejects on the weak intermediate. The server admin sees a good leaf and is baffled; the problem is upstream in the CA hierarchy.
3. An old certificate from before the 2048-bit era - A long-lived internal certificate, or one re-used across a fleet of embedded systems, minted back when 1024-bit was normal and simply never rotated. These are the “it’s been working fine since 2014” certificates that a browser update finally caught up with.

Diagnose with DechoNet

• SSL Check reads the server’s certificate and reports the key type and size for the leaf and the chain it presents. That tells you directly whether the weak key is the server certificate itself or an intermediate above it — the single fact you need to know which certificate to reissue.
• Running SSL Check from outside your network also isolates server from local: if the tool reports a healthy 2048-bit chain but Chrome still shows the error on your machine, the weak key is being introduced locally — a TLS-inspecting proxy or antivirus re-signing traffic with an undersized key — rather than by the real server.

Resolution Checklist

• Run SSL Check and read the key size for every certificate in the chain, not just the leaf. Identify which certificate is under 2048 bits — leaf, or intermediate.
• If it’s the leaf, reissue the certificate with a new 2048-bit RSA key (or an ECDSA P-256 key). You cannot upgrade an existing weak key in place — generate a fresh key pair and re-issue for it.
• If it’s an intermediate from a private/internal CA, the CA’s intermediate has to be replaced with one using an adequate key, and certificates re-issued underneath it. This is a CA-side fix, not a server-side one.
• For a factory device with a baked-in weak certificate, check for firmware that regenerates the certificate, or front the device with a reverse proxy terminating TLS on a modern certificate.
• If SSL Check shows a clean chain but the error only appears on one machine, disable any TLS-inspecting antivirus or corporate proxy — it’s re-signing with a weak key locally.
• Re-run SSL Check after reissuing to confirm every certificate in the presented chain is 2048-bit RSA or a modern ECDSA key.

When to Escalate

• If the weak certificate belongs to a network appliance or vendor device you can’t regenerate a key on, escalate to the vendor for firmware that issues a modern certificate — or put a reverse proxy in front and terminate TLS there.
• If the weak key is an intermediate in an internal PKI, hand it to whoever runs your CA; reissuing the intermediate and everything under it is a planned PKI operation, not a quick server change.
• Don’t reach for about:config or command-line flags to lower the browser’s key-size floor. That’s disabling a safety check for everyone on the machine, and with Chrome moving its floor up toward 2048, the certificate will only fail again soon — reissue instead.