Is ERR_SSL_DECRYPT_ERROR_ALERT a certificate problem?

No — and like every 'SSL' error, the name misleads. This isn't about trust, expiry, or hostname; the certificate was never rejected here. `decrypt_error` is a TLS handshake alert (code 51), and RFC 8446 §6.2 defines it exactly: 'A handshake (not record layer) cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message or a PSK binder.' The parenthetical is the whole story — 'not record layer' separates it from ERR_SSL_BAD_RECORD_MAC_ALERT, which fires on corrupted data *after* the handshake. decrypt_error fires *during* the handshake, when one side does a cryptographic check on something the other side sent — a signature, a Finished MAC, a resumption binder — and the math doesn't come out right. Reissuing the leaf certificate almost never helps, because the certificate's validity isn't what failed.

It only happens on a site that asks for a client certificate. Why?

That's the most common trigger, and it points straight at mutual TLS. When a server requires a client certificate, your browser signs a `CertificateVerify` message with your client key to prove you hold it. If the server can't verify that signature — the wrong key, a malformed client cert, a mismatched algorithm, or a smartcard/token that signed incorrectly — the server aborts with a fatal `decrypt_error`, and Chrome surfaces it as ERR_SSL_DECRYPT_ERROR_ALERT. Note the direction: this isn't Chrome complaining about the server's cert, it's the *server* rejecting *your* signature. That's what separates it from ERR_BAD_SSL_CLIENT_AUTH_CERT, where the browser bails around cert selection; here the handshake got far enough for the server to check your signature and reject it.

It fails across many HTTPS sites on one machine. Where's the problem?

A TLS-inspecting middlebox on your local path, almost certainly. Antivirus with HTTPS scanning, a corporate proxy, or a DLP appliance splices itself into the handshake, and if it desyncs the transcript — corrupts a signed message, mishandles a Finished hash, botches a TLS 1.3 resumption — the cryptographic verification on one side fails and emits decrypt_error. The tell is breadth: it hits many unrelated HTTPS sites on that one machine or network, not just one. If instead a single site fails for many users, or it correlates with session resumption, look server-side at whatever signs the handshake — a broken HSM, a buggy TLS terminator, or a bad session-ticket path.

Views: 22

ERR_SSL_DECRYPT_ERROR_ALERT in Chrome: Fix

ERR_SSL_DECRYPT_ERROR_ALERT means a TLS handshake signature failed, not a bad cert. Isolate client, middlebox, or server. 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

Chrome refuses to load the page with ERR_SSL_DECRYPT_ERROR_ALERT, and the instinct — check the certificate, reissue it, look at expiry — sends you down the wrong road. No certificate was found untrusted, expired, or misnamed. This error means Chrome received a fatal decrypt_error alert from the other side: somewhere in the handshake, one party performed a cryptographic verification and it failed. The connection is being torn down not because a cert is invalid, but because a signature, a Finished message, or a resumption binder didn’t check out.

Symptoms

Chrome (or any Chromium browser) shows net::ERR_SSL_DECRYPT_ERROR_ALERT, failing before the page ever renders.
It very often appears on endpoints that require a client certificate — corporate portals, government sites, mTLS-protected APIs.
It may hit every HTTPS site on one machine, which points at local security software rather than any one server.
curl or Firefox sometimes behaves differently, because whether you see the alert depends on which side failed the check and what’s in the path.
The certificate itself looks fine in every external checker — valid chain, not expired, correct name.

What This Error Actually Means

A TLS handshake isn’t just a cert exchange; it’s a sequence of cryptographic proofs. Each side signs or MACs specific messages so the other can verify that nobody tampered with the negotiation and that each party holds the private key it claims. The server signs its key exchange (and, with a client cert, verifies your CertificateVerify); both sides compute a Finished message over a hash of the entire handshake transcript; TLS 1.3 resumption adds a PSK binder. If any of those verifications fails, the checking side sends a fatal decrypt_error alert — TLS alert code 51 — and stops.

RFC 8446 §6.2 spells it out for TLS 1.3: “A handshake (not record layer) cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message or a PSK binder.” RFC 5246 §7.2.2 gives the TLS 1.2 version (a signature or Finished verification failure). Chrome maps the received alert to net error ERR_SSL_DECRYPT_ERROR_ALERT (internally -153).

The single most useful thing to hold onto: that word handshake. This is not ERR_SSL_BAD_RECORD_MAC_ALERT, which is a record-layer failure on encrypted data after the handshake completed. decrypt_error happens inside the handshake, on a cryptographic proof. So the fix is never “change the cipher suite” or “reissue the server cert” — those are handshake negotiation and trust concerns, and neither is what failed. What failed is a verification of something one side signed, and the diagnostic question is whose signature, and why it no longer verifies.

Top 3 Causes

mTLS: the server can’t verify your client certificate’s signature. On an endpoint that requires a client cert, your browser signs a CertificateVerify with your client key. If the server can’t verify it — wrong or unmatched key, malformed client cert, an algorithm the server won’t accept, or a smartcard/PKCS#11 token that signed incorrectly — it aborts with decrypt_error. This is the classic case, and the tell is that the site prompts for (or is configured to require) a client certificate. The server is rejecting your proof, not the other way around.
A TLS-inspecting middlebox desyncs the handshake. Antivirus HTTPS scanning, a corporate proxy, or a DLP appliance re-negotiates the handshake in the middle. If it corrupts a signed message or mishandles the transcript hash or a resumption binder, a Finished or signature check fails and one side emits decrypt_error. The tell is breadth — it fails across many unrelated HTTPS sites on that one machine or LAN.
A server-side signing or resumption bug. The server’s own signature path is broken: a failing HSM or crypto-offload card, a buggy TLS terminator, or a bad TLS 1.3 session-ticket / PSK-binder implementation that fails on resumption. The tell here is that it hits many clients, or tracks specifically with resumed connections rather than fresh ones.

Diagnose with DechoNet

SSL Check runs a full TLS handshake against your server from outside your network, with no client certificate. If it completes cleanly and returns a valid chain, the server’s normal handshake and signing are healthy — which means your failure is either the client-certificate leg (mTLS) or something on your local path, not the origin’s basic TLS. That split alone eliminates half the causes.
HTTP Check fetches the site from outside entirely. A clean external fetch while your own browser throws the alert puts the problem on your machine’s path — a local proxy or TLS-inspecting security product.

Resolution Checklist

Confirm it’s a handshake failure, not a record one: decrypt_error (this error) fires during the handshake; bad_record_mac fires after. They have different fixes — don’t chase network corruption for this one.
Does the site require a client certificate? If so, treat it as mTLS: verify you’re presenting the right client cert, that its key matches, and that any smartcard/token is signing correctly. This is the top cause.
Run an external SSL Check. Clean externally but broken in your browser → the problem is the client-cert leg or your local path, not the server’s core TLS.
If it fails on many HTTPS sites on one machine, disable TLS-inspecting antivirus or a corporate proxy and retest. If that clears it, the interception layer is desyncing handshakes — fix or reconfigure it.
If it hits many clients or only on resumed sessions, look server-side: test with TLS session resumption/tickets disabled, and check any HSM or hardware crypto offload for a signing fault.
Re-run the SSL check after each change to confirm the handshake completes end to end.

When to Escalate

If the endpoint requires a client certificate and yours is correct but the server still sends decrypt_error, escalate to whoever runs that server’s mTLS: their trust store, CA configuration, or signature-algorithm policy may be rejecting a valid client cert.
If an external SSL check shows a healthy server but one machine fails everywhere, hand it to whoever manages that endpoint’s security software — an inspecting proxy or antivirus is almost certainly desyncing the handshake, and only they can fix its TLS handling.
If the failure hits many clients or only resumed connections, give it to whoever owns TLS termination (CDN, load balancer, appliance vendor) as a handshake-signing or session-resumption bug, with the external handshake result as evidence that the certificate and chain are fine.