Does this mean the site was hacked or is running a fake certificate?

Not by itself. The error means one thing narrowly: the certificate chains to a publicly-trusted root, but Chrome could not find enough Signed Certificate Timestamps (SCTs) proving it was published to Certificate Transparency logs. That happens in two very different situations. Either the real server certificate genuinely was not logged — which is unusual because every major CA embeds SCTs automatically now — or something on your own machine or network is intercepting TLS and re-signing traffic with a certificate that still chains to a public root instead of a proper local one. The second case is far more common on a single machine, and it is why the same URL often loads fine on your phone over cellular. It is a legitimate signal worth investigating, not proof of an attack.

Why does my corporate proxy or antivirus trigger it when it's supposed to be allowed?

Chrome exempts TLS interception only when the intercepting root is installed as a *local* trust anchor — added to the OS or enterprise trust store by an administrator. When a root is trusted that way, CT is not enforced against certificates it issues, on the logic that a locally-added root is a deliberate local decision. The error appears when interception is happening but the substitute certificate still validates up to a *publicly*-trusted root, or the local root was never installed cleanly. So the fix is not to disable CT — it is to make the inspection root a proper local anchor, or to stop intercepting that connection.

How many SCTs does a certificate actually need?

Under Chrome's CT policy, a publicly-trusted certificate needs embedded SCTs from at least two distinct CT log operators, and the count scales with lifetime: at least two SCTs for certificates valid under 180 days, at least three for 180 days or longer. The two-operator rule matters more than the raw number — it stops a certificate from depending on any single log operator. If a log is later retired or disqualified, a certificate that only just met the bar through that log can silently drop below compliance, which is one way a certificate that worked last year starts throwing this error without anyone touching the server.

Views: 30

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED Fix

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED: no proof the cert was CT-logged. Tell a real cert from TLS interception in 3 checks. Free instant SSL check.

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 a site with a full-page warning: NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. The certificate isn’t expired and the name matches — the problem is that Chrome can’t find evidence the certificate was ever published to a public Certificate Transparency log.

Symptoms

A full-page interstitial in Chrome (or Edge/Brave) reading “Your connection is not private” with the CT code underneath.
The site loads fine in Firefox, or on a different device, or on the same site over mobile data instead of office Wi-Fi.
It hits every HTTPS site at once, or just one specific site — and which of those is your biggest clue.
The certificate itself looks valid: right hostname, not expired, trusted issuer.

What This Error Actually Means

Since Chrome 68 (July 2018), every publicly-trusted certificate issued after April 30, 2018 has to prove it was logged to Certificate Transparency. CT is the public, append-only ledger of certificates — the same system that lets anyone see every cert ever issued for their domain. Chrome enforces it because a mis-issued certificate that never appears in a log is exactly the kind of thing CT was built to catch.

The proof travels with the certificate as Signed Certificate Timestamps (SCTs) — small receipts from CT logs, usually embedded in the certificate at issuance. Chrome’s policy wants SCTs from at least two distinct log operators, and at least two or three of them depending on the certificate’s lifetime. No sufficient SCTs, no trust.

Here’s the part that makes this error diagnosable: Chrome only enforces CT against chains that end at a publicly-trusted root. A certificate that chains to a root an administrator installed locally — a corporate CA, a private internal CA — is exempt, on purpose. So when you see this error, you already know two things: the chain terminates at a public root, and that public chain is missing its transparency receipts. That narrows the world down to two real causes.

There’s also a quiet third variable. Chrome only enforces CT while its bundled log list is fresh — within about 70 days. A Chrome install that hasn’t updated in months stops enforcing CT entirely, then starts again after an update. If the error appeared “out of nowhere” right after a browser update, that timing is not a coincidence.

Top 3 Causes

TLS interception on your machine or network — Antivirus with HTTPS scanning, a corporate proxy, or a debugging tool is sitting in the middle, terminating TLS and re-signing it. If its root isn’t installed as a clean local trust anchor, Chrome treats the substitute certificate as a public chain missing SCTs. The tell: it hits every site, and clears the moment you leave that network or disable the scanner.
A genuinely un-logged public certificate — The real server certificate chains to a public root but wasn’t logged with enough SCTs. This is rare with modern CAs, which embed SCTs automatically, but happens with a privately-run intermediate that chains to a public root, an obscure CA that doesn’t log properly, or a certificate that met the bar through a CT log that has since been retired. The tell: it hits one site, from every network and device.
A stale or partially updated browser — Less a cause than a confound. A CT log getting disqualified, or Chrome’s log list rolling over, can flip a borderline certificate from compliant to non-compliant across an update. It’s why “it worked yesterday” is not evidence the server is fine.

Diagnose with DechoNet

SSL Check reads the certificate the server actually presents and cross-references it against crt.sh / Certificate Transparency logs. If the domain’s certificate is present in CT, the real server cert was logged — which points the finger at interception on your side rather than the server. If the served certificate differs from what CT shows, something is re-signing your traffic.
HTTP Check from our servers hits the site from outside your network entirely. If it connects cleanly while your browser throws CT errors, the problem is local — a proxy or scanner between you and the internet, not the site.

Resolution Checklist

Isolate local vs server first. Does the error hit one site or all sites? All sites = interception on your machine/network. One site = the certificate. This single question saves you most of the work.
If it’s all sites: temporarily disable your antivirus’s HTTPS/SSL scanning and test again. If it clears, the scanner is intercepting without a properly-installed local root. Re-enable it and either install its root as a local trust anchor (per the vendor’s docs) or exclude the affected sites from scanning.
If it’s a corporate network: the inspection root must be pushed to the OS/enterprise trust store by IT. Chrome exempts locally-added roots from CT; a root that isn’t installed that way is exactly what produces this error. This is an IT fix, not a browser setting.
If it’s one site and you own it: reissue the certificate from a CA that embeds SCTs — every mainstream ACME and commercial CA does. Confirm the new certificate carries embedded SCTs and appears in CT logs before deploying.
Update Chrome and retest. If the error surfaced right after an update, a log-list change may have exposed a certificate that was always borderline.
Re-run the SSL Check to confirm the served certificate is logged and the chain terminates where you expect.

When to Escalate

If every HTTPS site breaks on a managed corporate device, this is IT’s problem, not yours. The inspection root needs to be deployed correctly to the trust store; you can’t fix a policy-managed proxy from the browser.
If your own site throws CT errors for visitors and the SSL Check shows the certificate missing from CT logs, escalate to your CA. A publicly-trusted certificate that isn’t logged is a mis-issuance on their side, and reissuance is the fix — not a workaround in your server config.