sfw/fix
ERR_CERTIFICATE_TRANSPARENCY_REQUIRED high

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Chrome blocks the cert because it can't prove the cert was publicly logged — there are no valid SCTs attached.

What you see

Your connection is not private

Attackers might be trying to steal your information from example.com (for example, passwords, messages, or credit cards).

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

What’s actually happening

The page is replaced by the full interstitial before anything renders. Chrome requires that publicly-trusted TLS certs issued after April 30, 2018 prove their inclusion in public Certificate Transparency logs, enforced since Chrome 68. That proof is a set of Signed Certificate Timestamps (SCTs). When Chrome sees none — or only SCTs from logs it no longer trusts — it refuses the cert even though it may be in-date and chain to a trusted root. Firefox doesn't enforce CT the same way, so a site failing only in Chrome with this code is a strong hint.

Common causes

  • A publicly-trusted cert was issued without embedded SCTs — the CA didn't submit it to CT logs, or the SCTs were stripped.
  • The SCTs present come from CT logs Chrome has since distrusted or retired, so they no longer count.
  • SCTs were meant to be delivered via OCSP stapling or a TLS extension, but stapling is broken/disabled, so none reach the browser.
  • A privately-issued cert from an internal CA is being served on a hostname Chrome treats as public — CT isn't enforced for locally-installed (enterprise) roots, so the fix differs depending on which case you're in.
  • A cert was minted by an appliance or internal tool that has no path into public CT logs at all.

How to fix it

  1. Check whether the cert carries SCTsOpen the cert in Chrome DevTools → Security panel, or run `openssl s_client -connect example.com:443 | openssl x509 -noout -text | grep -i -A2 'SCT\|Signed Certificate Timestamp'`. No SCT block means the cert was never logged. You can also search the hostname on crt.sh to see if it's in public CT logs at all.
  2. Reissue from a CA that submits to CT logsFor a public-facing site, get the cert from any mainstream public CA — they all embed SCTs at issuance now (Let's Encrypt, DigiCert, etc.). Reissue, install, and the embedded SCTs travel with the cert automatically. This is the fix in the overwhelming majority of cases.
  3. Repair SCT delivery if stapling was the planIf your cert relied on OCSP-stapled SCTs, confirm stapling actually works (`openssl s_client -status ...` should show an OCSP response). Embedded SCTs are more reliable — prefer reissuing with them over depending on stapling.
  4. Handle the internal-CA case correctlyIf this is a genuinely internal cert from your own CA, CT isn't required for it as long as that root is installed via your OS/enterprise trust store on the client. Distribute the internal root through MDM/Group Policy. Don't try to log a private cert publicly.

Stop it recurring

Use a public CA that embeds SCTs for anything internet-facing, and keep internal-CA roots in the OS trust store rather than serving private certs on public hostnames.

Related errors