Is NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED the same as ERR_CERT_AUTHORITY_INVALID?

No — it's a more specific, and more serious, verdict. ERR_CERT_AUTHORITY_INVALID just says the certificate chains to a root your browser doesn't trust; the cause could be anything from a self-signed dev cert to a missing intermediate. ERR_CERT_KNOWN_INTERCEPTION_BLOCKED says Chrome recognized the offending certificate as one that is known to be used for intercepting traffic. Chrome's own error code -217 spells it out: 'The certificate is known to be used for interception by an entity other than the device owner.' So it's not a generic 'untrusted issuer' — it's Chrome telling you the reason your connection is being tampered with is a certificate from a known TLS-interception product, and it's refusing to let that quietly pass as an ordinary trust error.

It happens on every HTTPS site. What does that mean?

That pattern almost always means the interception is happening locally — on your machine or your network — not on any individual website. Something between you and the internet is terminating TLS, re-signing every certificate with its own issuer, and that issuer is one Chrome recognizes as a known interceptor while your system doesn't trust it as a root. The usual suspects are antivirus or 'web shield' HTTPS scanning that installed itself badly or got half-removed, a corporate proxy or firewall doing TLS inspection whose root was never deployed to your trust store, or, at the bad end, adware or malware doing the same thing without your consent. A single website can't cause this across every site — the common element is the thing sitting in front of all of them.

How do I fix it — and is clicking through safe?

There's no 'proceed anyway' bypass to lean on here, and that's deliberate: this error exists specifically to stop you from waving past interception. The fix depends on who is intercepting. If it's software you know about — corporate TLS inspection, a monitoring product your IT team runs — the interceptor's root certificate has to be installed properly into the operating system trust store; once the device owner has authorized it, Chrome downgrades to an informational note instead of blocking. If it's antivirus HTTPS scanning you didn't ask for, disable that feature or the product and see if the error clears. If you don't recognize the interceptor at all, treat it as hostile: scan for adware/malware and inspect any proxy or PAC settings that got changed. The one thing that is never the answer is blaming the website — the site's real certificate is fine; something in the path replaced it.

Views: 33

NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED: MITM

NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED means Chrome flagged an interception cert in your TLS chain. See who is intercepting in 3 checks. Free instant SSL 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 the page with NET::ERR_CERT_KNOWN_INTERCEPTION_BLOCKED and a “Your connection is not private” screen. This is not the ordinary untrusted-certificate error. Chrome is saying it looked at the certificate your connection is actually using, recognized it, and knows that certificate is used to intercept traffic.

The Chromium error table is unusually direct here — code -217: “The certificate is known to be used for interception by an entity other than the device owner.” Read that last clause slowly. Chrome isn’t just refusing an unknown issuer. It’s refusing a known one, and specifically flagging that the interception is being done by someone other than the person who owns the machine. That framing is the whole point of the error.

Symptoms

The exact code is ERR_CERT_KNOWN_INTERCEPTION_BLOCKED, not the generic ERR_CERT_AUTHORITY_INVALID — Chrome went out of its way to be specific.
It very often hits every HTTPS site at once, not just one. That breadth is the loudest clue.
There’s no easy “proceed to site (unsafe)” link to click past — the block is firmer than a normal certificate warning.
It frequently appears right after installing or updating antivirus/“internet security” software, joining a corporate network, or picking up unwanted software.
If you inspect the certificate, the issuer is not the site’s real CA — it’s some security product, appliance, or proxy vendor.

How Chrome Knows It’s Interception

Chrome ships a constantly-updated data structure called a CRLSet, pushed to the browser out of band. Alongside emergency certificate revocations, that set carries a flag marking certificates that are known to be used for interception — the roots and intermediates that TLS-inspecting middleboxes, DPI appliances, and HTTPS-scanning security products sign with.

There are two states, and the difference matters. If such a certificate is present but the device owner has trusted its root — you (or your IT department) installed the interceptor’s CA into the operating system’s trust store — Chrome treats it as detected: it doesn’t block, it just knows interception is happening. But if the interception certificate is flagged as known and your system doesn’t trust it as a legitimate root, Chrome escalates to blocked and throws ERR_CERT_KNOWN_INTERCEPTION_BLOCKED. In other words: authorized interception with a properly-installed root gets a quiet note; interception by a certificate Chrome recognizes but your machine never sanctioned gets stopped.

That’s why the error is really a statement about your environment, not the website. Some product is standing between your browser and the server, terminating TLS and re-issuing certificates, and it’s doing so with a credential Chrome recognizes and your OS doesn’t trust. The website’s own certificate — the real one — never reached you.

Top Causes

Antivirus or “web shield” HTTPS scanning - Security suites that inspect encrypted traffic install a local root and re-sign every certificate. When that install is broken, half-removed, or its root isn’t properly trusted, Chrome sees a known interceptor it can’t validate and blocks. This is the most common cause of the “every site fails” version.
A corporate proxy or firewall doing TLS inspection - Enterprise networks routinely decrypt and re-encrypt outbound HTTPS. That’s legitimate when the company’s inspection root is pushed to every managed device. On a device where that root was never installed — a personal laptop on the corporate Wi-Fi, a missed deployment — the interception is recognized but untrusted, and Chrome blocks it.
Adware or malware installing a rogue root - The hostile version. Unwanted software plants its own CA and routes your traffic through it to inject ads or harvest data. If you don’t recognize the interceptor at all, assume this until proven otherwise.
A middlebox or appliance in the network path - Some captive or managed networks run interception at the gateway. Same mechanism: your traffic is being re-signed by something Chrome knows and your machine doesn’t trust.

Diagnose with DechoNet

SSL Check inspects the certificate the server actually presents, from outside your local network — so it sees the real chain, not the one your interceptor swapped in. That comparison is the whole diagnosis: if DechoNet reports a normal certificate from the site’s genuine public CA while your browser shows an unfamiliar security-product issuer, the interception is happening locally, between you and the server. The site is fine; something on your side replaced its certificate.
DNS Check confirms you’re resolving the host to its real address and aren’t being quietly redirected somewhere that would explain a substituted certificate. It rules out the case where the “interception” is actually you talking to the wrong endpoint entirely.

Resolution Checklist

Note the scope. Does it hit every HTTPS site or just one? Every site points squarely at a local interceptor — software on your machine or a device on your network.
Read the certificate’s issuer in the browser (click the “Not secure” area → certificate details). The issuer name usually names the culprit: an antivirus vendor, a firewall brand, a proxy product, or something you don’t recognize.
Cross-check with an SSL check. If DechoNet sees the site’s real, publicly-trusted certificate and your browser sees a security product’s, you’ve confirmed the interception is local — not a server problem.
If it’s antivirus/“internet security” HTTPS scanning, turn that feature off (or uninstall the product) and re-test. Many suites call it “HTTPS scanning,” “encrypted connection scanning,” or “web shield.”
If it’s sanctioned corporate inspection, the interceptor’s root must be installed into your OS trust store by whoever manages it — that’s what turns a block into an allowed, detected interception. Don’t improvise your own root install for a device you don’t administer.
If you don’t recognize the interceptor, treat it as hostile: run a reputable adware/malware scan and audit proxy and PAC settings for anything you didn’t set.

When to Escalate

If this is a managed or corporate device, escalate to IT. Sanctioned TLS inspection is supposed to ship its root to every device; a block means the deployment missed yours, and only they can fix the trust configuration correctly.
If the interceptor is unknown and you can’t remove it, treat it as a security incident, not a browser annoyance. A certificate Chrome recognizes as an interceptor, sitting in your traffic without your consent, means something is reading your encrypted connections — get the machine cleaned before you log into anything sensitive.