Is ERR_SSL_BAD_RECORD_MAC_ALERT a certificate problem?

No, and the 'SSL' in the name sends everyone down the wrong path. By the time this alert fires, the certificate has already been presented, validated, and accepted — the connection is fully encrypted and both sides have agreed on keys. bad_record_mac is a TLS alert (code 20) that means a record arrived that couldn't be authenticated: in TLS 1.2 the MAC didn't match, in TLS 1.3 the AEAD tag didn't verify (RFC 8446 §6.2 uses this one alert for all deprotection failures). The encrypted bytes were altered, truncated, or reordered somewhere between the two endpoints. Replacing or reissuing the certificate does nothing, because the cert was never the issue.

Why does it happen on Wi-Fi but not on a wired connection?

Because the corruption is usually physical or path-level, and a flaky radio link is the most common place for a TLS record to get mangled before its integrity check. Weak Wi-Fi, an overloaded router with a mismatched MTU that fragments records badly, a failing NIC or cable, even bad RAM on a middlebox — any of these can flip or drop bytes inside an encrypted record. TLS is doing exactly its job: it detects that the ciphertext was tampered with or damaged and refuses to trust it rather than handing your app corrupted data. Switching to Ethernet or a different network often makes it vanish, which is itself a strong diagnostic signal.

The site works for other people but fails for me. Where's the problem?

On your side of the connection, almost certainly. If an external TLS check completes a clean handshake and other clients load the site fine, the server's crypto is healthy and the record is being corrupted on your local path — most often TLS-inspecting antivirus or a corporate proxy that re-encrypts traffic and gets its record framing wrong, or a bad local link. If instead the failure hits everyone, or clusters under load, suspect a shared middlebox: a load balancer doing TLS offload with a hardware bug, or an inline security appliance mangling records for all traffic through it.

Views: 13

ERR_SSL_BAD_RECORD_MAC_ALERT in Chrome: Fix

ERR_SSL_BAD_RECORD_MAC_ALERT means a TLS record was corrupted, not a bad certificate. Check MTU, Wi-Fi, and antivirus. 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 fails to load the page with ERR_SSL_BAD_RECORD_MAC_ALERT, and the first instinct — reissue the certificate — is exactly wrong. No certificate was rejected here. By the time this error appears, the cert has already been presented and accepted, keys have been exchanged, and the connection is encrypted. This error fires inside that encrypted channel, and it means one side received an encrypted record it could not authenticate.

Symptoms

Chrome (or any Chromium browser) shows net::ERR_SSL_BAD_RECORD_MAC_ALERT, often part-way through loading rather than on the very first request.
It’s frequently intermittent — a reload sometimes works, sometimes doesn’t — and correlates with a weak or busy network.
It clears when you switch from Wi-Fi to Ethernet, change networks, or disable a security product.
Other people load the same site fine, or the same machine fails on multiple unrelated HTTPS sites.

What This Error Actually Means

TLS doesn’t just encrypt data, it authenticates every record. When one side sends an application record, it protects it — in TLS 1.2 by appending a MAC computed over the contents, in TLS 1.3 by sealing it with an AEAD cipher whose tag covers the whole record. The receiver recomputes or verifies that protection before it will decrypt and use the data. If the check fails, the receiver has no way to know whether it’s looking at a transmission error or a deliberate tampering attempt, so it assumes the worst: it aborts the connection and sends a fatal bad_record_mac alert, TLS alert code 20 (RFC 5246 §7.2.2 for TLS 1.2, RFC 8446 §6.2 for TLS 1.3). Chrome surfaces that alert as ERR_SSL_BAD_RECORD_MAC_ALERT.

So the translation is blunt: an encrypted record arrived corrupted, and TLS refused to pretend it was fine. That’s a feature. The protocol is designed to fail loudly rather than quietly deliver damaged bytes to your application. The whole diagnostic question becomes where the record got corrupted — a physical link, a piece of middleware re-encrypting the stream, or a buggy TLS terminator.

One important consequence: this is almost never something you fix by changing the certificate, the cipher suite, or the TLS version. Those are handshake concerns, and the handshake already succeeded. You’re debugging data integrity on an established channel.

Top 3 Causes

A flaky or misconfigured network path corrupts records - The classic case. Weak Wi-Fi dropping and re-sending frames, a router with a low or mismatched MTU that fragments TLS records awkwardly, a failing NIC, cable, or driver — any of these can alter the bytes inside an encrypted record in transit. TLS catches the damage that TCP’s checksum missed and aborts. This is why the error is so often intermittent and network-specific, and why moving to Ethernet or another connection makes it disappear.
TLS-inspecting security software mangles the re-encrypted stream - Antivirus with HTTPS scanning, a corporate proxy, or a DLP appliance intercepts the connection, decrypts it, inspects it, and re-encrypts it to the browser. If that re-encryption has a bug — a record framing error, a desynced sequence number, a broken cipher implementation — the browser receives records whose MAC/tag doesn’t verify. The tell is that it happens across many different HTTPS sites on one machine, not just yours.
A load balancer or middlebox doing TLS offload has a bug - Server-side, an appliance terminating TLS (hardware crypto offload, an older LB firmware, an inline IPS) can corrupt records under specific conditions or under load. Here the failure tends to hit many or all clients, or track with traffic volume, rather than following one user around.

Diagnose with DechoNet

SSL Check runs a full TLS handshake against your server from outside your network and reads back the record layer. If it completes cleanly and returns a valid chain, your server’s TLS is healthy and the corruption is happening on the client’s path — not the origin. That single result splits the problem in half.
HTTP Check fetches the site from outside your network entirely. A clean external fetch while your own browser fails points squarely at your local link, proxy, or security software.

Resolution Checklist

Isolate client vs. server first. Run an external TLS check (or open the site from a different network / mobile hotspot). Clean externally but broken on your network → the problem is your path, not the site.
Switch Wi-Fi to Ethernet, or move to a different network. If the error vanishes, you’ve confirmed a physical-link or router issue — check for a failing cable/NIC and for an MTU set too low (try lowering, then normalizing, the interface MTU).
Temporarily disable TLS-inspecting antivirus or a corporate proxy and retest. If that fixes it, the interception layer is corrupting records — update or reconfigure it rather than leaving HTTPS scanning off permanently.
If it fails for everyone or scales with load, look server-side at whatever terminates TLS: update load balancer / appliance firmware, and test with hardware crypto offload disabled to rule out an offload bug.
Re-run the SSL check after each change to confirm the record layer stays clean end to end.

When to Escalate

If an external SSL check shows a healthy server but one specific machine keeps failing across multiple sites, escalate to whoever manages that endpoint’s security software — an inspecting proxy or antivirus is the near-certain culprit, and only they can fix its TLS handling.
If the failure tracks with load or hits all clients, hand it to whoever owns TLS termination (CDN, load balancer, appliance vendor) as a record-corruption bug, with the external handshake result as evidence that the certificate and handshake are fine.
If it’s confined to one office network and no single machine, it’s the shared path — give it to the network team to check the middlebox chain and link quality between the site and the edge.