Can I fix this in my browser? Clearing cache didn't help.

No, and it never will — nothing you do on the client side fixes it, because nothing on the client side is broken. This error means the *server* offered a Diffie-Hellman key too small to be safe, and your browser refused to negotiate down to it. Cache, cookies, extensions, and TLS settings on your machine have nothing to do with it. The only real fix lives on the server: raise its DH parameters to 2048 bits or move it to ECDHE cipher suites. If it's not your server, the honest options are to tell the operator, or accept that a browser protecting you from a 1990s-grade key is doing its job.

Why do I get a cipher-mismatch error in Chrome but ERR_SSL_WEAK_EPHEMERAL_DH_KEY somewhere else?

Because Chrome stopped speaking the vulnerable protocol entirely. After the 2015 Logjam disclosure, browsers set a hard floor of 1024 bits on Diffie-Hellman groups; then in 2016 Chrome (and Safari) removed DHE cipher suites altogether in favor of ECDHE. So a modern Chrome hitting a DHE-only server with weak parameters now finds no common cipher and reports a version-or-cipher mismatch, not this string. You still see the classic `ERR_SSL_WEAK_EPHEMERAL_DH_KEY` — or Firefox's "SSL received a weak ephemeral Diffie-Hellman key," or OpenSSL's blunt `dh key too small` — from older browsers, embedded clients, `curl`, and Java. Same server flaw, different client vocabulary.

The server uses a 1024-bit DH group. Isn't that above the floor?

Barely, and that's the problem. 1024 bits is the minimum browsers tolerate, not a safe target. Logjam's real lesson wasn't about 512-bit export ciphers — it was that a tiny set of 1024-bit primes is hard-coded and reused across millions of servers, so a single, enormous precomputation per prime puts passive decryption of 1024-bit DHE within reach of a well-funded adversary. Strict clients, scanners, and compliance scans increasingly reject 1024-bit DHE for exactly this reason. Generate a fresh 2048-bit group, or better, drop DHE for ECDHE and sidestep the whole shared-prime trap.

Views: 27

ERR_SSL_WEAK_EPHEMERAL_DH_KEY: It's the Server

ERR_SSL_WEAK_EPHEMERAL_DH_KEY: a server's Diffie-Hellman key is too small to trust. Fix it with strong DH params or ECDHE. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

ERR_SSL_WEAK_EPHEMERAL_DH_KEY looks like a browser error, and it is — but the thing it’s complaining about is entirely on the other end of the wire. Your browser started a TLS handshake, the server picked an ephemeral Diffie-Hellman (DHE) cipher, and the Diffie-Hellman group the server offered was so small that the browser refused to finish. It would rather show you an error page than establish a connection anyone with a budget could later decrypt.

So the first thing to internalize is that this is not your fault and not your fix. There is no client-side toggle, cache purge, or setting that makes it go away honestly. The error is the browser enforcing a floor — a floor the internet agreed to after Logjam in 2015 (CVE-2015-4000). The Logjam researchers showed that a man-in-the-middle could force a TLS session down to export-grade 512-bit Diffie-Hellman and then break it, and — the part that actually mattered — that because a handful of 1024-bit primes are baked into common server software and reused everywhere, precomputing against one prime could unlock passive decryption for a huge swath of the internet at once. Browsers responded by rejecting DH groups under 1024 bits, and treating anything that trips the check as a hard stop.

Symptoms

Chrome/Chromium of the era shows ERR_SSL_WEAK_EPHEMERAL_DH_KEY and won’t load the page.
Firefox shows “SSL received a weak ephemeral Diffie-Hellman key” (SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY).
curl or openssl s_client fail with dh key too small; Java throws a “DH keypair too small” / key-size error.
It’s one specific site or device — usually something old — while the rest of the web loads normally. On up-to-date Chrome you may instead get a cipher mismatch, because Chrome dropped DHE entirely.

Top 3 Causes

The server offers export-grade or sub-1024-bit DHE - The outright-broken case. A legacy TLS config still advertises DHE_EXPORT or a 512/768-bit Diffie-Hellman group — leftover export ciphers, an ancient OpenSSL, or a copy-pasted config from a decade ago. Every current client rejects it. This is the literal thing Logjam was about, still running.
The server uses the old default 1024-bit shared prime - The “technically at the floor, still not okay” case. Many older builds of Apache and nginx defaulted to a well-known 1024-bit group. Browsers grudgingly allow 1024, but strict clients, security scanners, and compliance checks increasingly flag it — because it’s a shared prime, which is exactly the weakness Logjam exploited. You’re one policy tightening away from it breaking.
A legacy appliance nobody updates - The stubborn case. iDRAC/IPMI controllers, network switches, printers, old mail servers, and management consoles ship with tiny DH parameters and never get touched. You don’t hit them in Chrome — Chrome won’t talk DHE — you hit them through curl, an SDK, Java, or an old browser, and get the weak-key error there.

Diagnose with DechoNet

SSL Check confirms the server is reachable over TLS and shows its certificate and handshake posture, so you can establish the obvious first: the problem is the server’s TLS configuration, not your machine. Once you know the server is the constant, the exact culprit is one command away.
Get the precise Diffie-Hellman size with OpenSSL: openssl s_client -connect yourdomain.com:443 -cipher DHE and read the Server Temp Key line — it prints the DH group size in bits (e.g. DH, 1024 bits). Anything at or below 1024 is what’s tripping clients.

Resolution Checklist

Confirm the DH size: openssl s_client -connect host:443 -cipher DHE 2>/dev/null | grep "Server Temp Key". DH, 512 bits or DH, 1024 bits is your answer.
Prefer the clean fix — drop DHE for ECDHE. Configure the server for elliptic-curve ephemeral key exchange only (modern cipher lists do this by default) and the shared-prime problem disappears entirely. This is what browsers pushed everyone toward for a reason.
If you must keep DHE (a client that needs it), generate a strong group: openssl dhparam -out /etc/ssl/dhparams.pem 2048 (2048 minimum; 4096 if you can afford the handshake cost). Point the server at it — nginx: ssl_dhparam /etc/ssl/dhparams.pem;; Apache 2.4.8+ with OpenSSL 1.0.2+: SSLOpenSSLConfCmd DHParameters "/etc/ssl/dhparams.pem".
Explicitly disable export and weak ciphers so nothing can negotiate back down (!EXPORT:!LOW:!aNULL in your cipher string). Reload and re-run the openssl check to confirm the new size.
For an appliance you can’t reconfigure, put a modern reverse proxy or load balancer in front of it and terminate TLS there — the appliance can speak its weak crypto on an internal segment while the public endpoint uses ECDHE.

When to Escalate

If it’s not your server — a vendor portal, a partner API, a device’s built-in web UI — the fix is theirs. Send the operator the Server Temp Key output; “your DH group is 1024 bits, browsers are starting to reject it” is a specific, actionable bug report, not a vague complaint.
If a device genuinely cannot be updated and cannot sit behind a proxy, don’t reach for the browser flags that re-enable weak DH. That doesn’t fix anything — it just turns your client into the one machine willing to accept a key an attacker could crack, on every site, not only this one.
If you find weak DHE on infrastructure you thought was modern, treat it as a config-drift finding, not a one-off. A 1024-bit default hiding in one service usually means the same template is deployed elsewhere — audit the rest before a scanner or a stricter browser finds it for you.