ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN: MITM

Problem

Chrome refuses the page with NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN and a “Your connection is not private” screen, almost always on a Google property — Search, YouTube, Gmail, or something loading Google resources. This is not a normal certificate error. The certificate is otherwise valid; Chrome is rejecting it because its public key isn’t the one Chrome has pinned for that host.

Chromium’s error table is blunt about it — code -150: the certificate “did not match the built-in public key pins for the host name.” Read that carefully. It’s not saying the certificate is untrusted. It’s saying the certificate is trusted and wrong — a valid chain presenting the wrong key for a name where Chrome knows which key it should be.

Symptoms

• The exact code is ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, not the generic ERR_CERT_AUTHORITY_INVALID.
• It hits Google-owned sites — google.com, youtube.com, mail.google.com, gstatic.com — while unrelated sites work fine.
• It frequently starts right after installing or updating antivirus / “internet security” software, or joining a corporate or public network.
• If you inspect the certificate, the issuer isn’t Google Trust Services — it’s an antivirus vendor, a proxy appliance, or something you don’t recognize.
• There’s no clean “proceed anyway” bypass; the block is firmer than an ordinary warning.

How Chrome Decides the Key Is Wrong

Chrome ships with a built-in set of public-key pins. For a pinned host, at least one key in the certificate chain the server presents must match a key on that list. If the chain validates perfectly but none of its keys are pinned, Chrome throws ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN. The check runs after normal validation, so the certificate has already passed trust, dates, and hostname — it fails on identity alone.

Here’s the part that turns this from a mystery into a diagnosis. Chrome deliberately does not enforce pins when the chain terminates at a locally-installed (private) trust anchor. If you — or your IT department — installed a custom root CA on the machine, and the intercepting certificate chains up to that root, Chrome skips the pin check entirely. This is intentional: it’s how corporate TLS inspection and antivirus HTTPS scanning are allowed to work without breaking pinned sites.

So the error firing tells you something specific: whatever re-signed the certificate is not chaining to a properly-installed local root. Either its root was never installed into your trust store, or it’s re-signing with a publicly-trusted certificate that isn’t Google’s. Both are interception; neither is a website problem. The one thing this is almost never is the actual site — Google’s real certificate never reached your browser.

Top Causes

1. Antivirus or “web shield” HTTPS scanning — Security suites that inspect encrypted traffic re-sign every certificate. When their local root isn’t cleanly installed (a half-finished install, a botched update), the re-signed Google cert has no pinned key and no trusted local anchor to exempt it, so Chrome blocks. The most common cause of the “only Google is broken” version.
2. A corporate proxy or firewall doing TLS inspection — Enterprise networks decrypt and re-encrypt outbound HTTPS. On a device where the inspection root was never installed — a personal laptop on corporate Wi-Fi, a missed deployment — the interception is visible and unexempted, and pinned Google domains break while the rest of the web limps along.
3. Adware or malware with a rogue root — The hostile version. Unwanted software routes traffic through its own CA to inject ads or harvest data. If you don’t recognize the issuer at all, assume this until proven otherwise.
4. A stale pin or HSTS entry (historical) — Rarely, an old dynamic pin cached from the pre-2018 HPKP era lingers in Chrome’s internal state. Clearing the host’s entry in chrome://net-internals/#hsts resolves that specific case, but it is not the usual cause today.

Diagnose with DechoNet

• SSL Check inspects the certificate the server actually presents, from outside your local network — so it sees Google’s real chain, not the one your interceptor swapped in. Run it against a Google-owned host: if DechoNet reports a normal Google Trust Services certificate while your browser shows an unfamiliar security-product issuer, the interception is happening locally, between you and the server. That comparison is the whole diagnosis.
• DNS Check confirms you’re resolving the host to a real Google address and aren’t being redirected somewhere that would explain a substituted certificate. It rules out the case where you’re quietly talking to the wrong endpoint entirely.

Resolution Checklist

• Note the scope. Does it hit only Google-owned sites while everything else works? That’s the signature of a local interceptor Chrome only catches on pinned domains.
• Read the certificate’s issuer in the browser (click the “Not secure” area → certificate details). If it names an antivirus vendor, a firewall brand, or a proxy product instead of Google Trust Services, you’ve found the interceptor.
• Cross-check with an SSL check from outside. DechoNet seeing Google’s real certificate while your browser sees a security product’s confirms the interception is local, not a server fault.
• If it’s antivirus / “internet security” HTTPS scanning, turn that feature off (often called “HTTPS scanning,” “encrypted connection scanning,” or “web shield”) and re-test.
• If it’s sanctioned corporate inspection, IT must install the inspection root correctly — and most enterprise proxies are configured to bypass pinned domains precisely to avoid this. Report it; don’t improvise a root install on 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.
• Only if the error persists on one host with no visible interceptor, clear that host in chrome://net-internals/#hsts to drop any stale cached pin.

When to Escalate

• On a managed or corporate device, escalate to IT. Sanctioned inspection is supposed to either ship its root to every device or exclude pinned Google domains; a pin failure means the deployment did neither on your machine, and only they can fix it correctly.
• If the interceptor is unknown and you can’t remove it, treat it as a security incident, not a browser annoyance. Something is re-signing your encrypted connections to Google without your consent — get the machine cleaned before you sign into anything sensitive.
• If you’re a website owner told your site throws this, stop looking at your server. Unless you operate a Google-pinned domain, your certificate can’t trip this pin; the failure lives in the visitor’s environment.