How to Fix the NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED Error

Most SSL connection errors give you something to try. This one does not. When Chrome shows NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, the connection was refused because of what the site’s certificate contains, or rather what it fails to contain, and none of the usual visitor-side fixes take part in that decision.

This guide explains what the error actually checks, how to confirm the cause on a certificate you control, and what to do about it. It is written mainly for site owners, because they are the only people who can resolve it.

Quick answer:

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED means Chrome rejected a site’s SSL certificate because it did not arrive with enough valid Certificate Transparency proof, in the form of Signed Certificate Timestamps (SCTs). Chrome requires at least two SCTs for certificates valid 180 days or less, and at least three for longer ones, from at least two different log operators.

Only the site owner can fix it, by asking the Certificate Authority to reissue the certificate with SCTs embedded in it. Visitors cannot fix this error: clearing the cache, clearing the SSL state, and disabling extensions have no effect on certificate verification.

What the NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error means

Certificate Transparency (CT) is a public audit system for SSL certificates. Every publicly trusted certificate is submitted to append-only public logs, so that domain owners and researchers can see what has been issued for their names and catch misissuance. A log returns a signed receipt for each submission, and that receipt is called a Signed Certificate Timestamp, or SCT.

Chrome does not check whether a certificate is in a log by querying the log during your connection. It checks the receipts. When the certificate reaches the browser without enough acceptable SCTs, Chrome cannot confirm the certificate was publicly disclosed, so it fails the connection and shows NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

Two consequences follow, and both matter for troubleshooting:

• The judgment happens inside certificate verification, using data that arrived from the server. Browser settings, cached files, saved cookies, and extensions are not part of that path, so changing them cannot change the outcome.
• The problem originates with whoever issued or deployed the certificate. That is the Certificate Authority, or the server configuration, or both.

How SCTs reach the browser

You cannot diagnose this error without knowing how the receipts travel. There are three delivery methods, and one of them stopped working in 2026.

• Embedded in the certificate. The CA logs a precertificate, collects the SCTs, and writes them into the final certificate as an X.509v3 SignedCertificateTimestampList extension (OID 1.3.6.1.4.1.11129.2.4.2). This is how the overwhelming majority of certificates deliver CT proof, and it requires nothing from your server: the SCTs travel with the certificate.
• Via a TLS extension. The server supplies SCTs during the handshake rather than carrying them in the certificate. This works, but it has to be configured and maintained on the server.
• Stapled in an OCSP response. Chrome accepted this through version 147. Chrome 148, released on May 5, 2026, removed it.

That last change is the most likely reason a site that worked for years started failing in 2026. If your deployment relied on SCTs arriving in a stapled OCSP response, nothing about your certificate or server changed, but Chrome stopped counting those SCTs. The certificate now needs embedded SCTs, which means a reissue.

How many SCTs Chrome requires

“Insufficient Certificate Transparency” is a counting rule, not a yes-or-no check. For SCTs embedded in the certificate, Chrome’s CT policy requires:

• Two SCTs from distinct logs for a certificate valid 180 days or less.
• Three SCTs from distinct logs for a certificate valid longer than 180 days.
• Among those, at least two must come from different log operators. Two receipts from two logs run by the same company do not satisfy the policy.

The 180-day boundary is easy to trip over right now. Public certificates can be issued for up to 200 days as of March 15, 2026, and a 200-day certificate sits in the longer bracket, so it needs three embedded SCTs rather than two.

Two further conditions decide whether a given SCT counts at all:

• Chrome uses its own list of recognized logs. An SCT from a log that Chrome does not list is not a policy violation as such, it simply does not count toward the total. A certificate can carry several SCTs and still fail.
• Retired logs have a cutoff. When a log is retired, SCTs it issued before its Retired timestamp keep counting, and SCTs issued after it do not.

How to fix the error as a website owner

1. Look at the SCTs in your certificate

Start by finding out what your server is actually sending. Connect to it and print the certificate’s SCT extension:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A 4 "CT Precertificate SCTs"

A healthy certificate returns a block like this, with one entry per SCT:

CT Precertificate SCTs:
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
                    B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
        Timestamp : Jun  6 21:44:12.318 2026 GMT

To count the receipts instead of reading them, use:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -c "Signed Certificate Timestamp:"

Compare that number against the requirement for your certificate’s validity period. A result of 0 means there are no embedded SCTs at all, which points either to a certificate that was never logged or to a deployment that was relying on OCSP or TLS delivery.

One caveat on macOS: the bundled /usr/bin/openssl is LibreSSL, which does not decode this extension. It prints the bare OID instead, so on a stock macOS toolchain the first command returns nothing and the count returns 0, even on a perfectly healthy certificate carrying the full set of SCTs. Do not read that 0 as a missing receipt. Either install OpenSSL through Homebrew, confirming with openssl version that you are calling it rather than the system binary that still sits earlier on PATH, or search for the raw identifier, which LibreSSL does report:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep "1.3.6.1.4.1.11129.2.4.2"

You can also review the certificate’s chain, expiry, and installation with our free SSL Checker, which is useful for ruling out the ordinary problems that get confused with this one.

2. Ask your CA to reissue the certificate

If the certificate carries no embedded SCTs, or fewer than the policy requires, the fix is a reissue. Contact your Certificate Authority, quote the error, and ask them to reissue with the required SCTs embedded. Reissues are normally free within the certificate’s term, and there is nothing you can configure on your own server to add SCTs to a certificate that was issued without them.

This should be a rare situation today. Since June 15, 2026, the Chrome Root Program requires CA owners to log every TLS precertificate to at least one log that Chrome recognizes as Usable or Qualified before issuing the corresponding certificate. A publicly trusted certificate issued now should arrive compliant. If your CA is slow to resolve it or cannot explain why the certificate was issued without sufficient SCTs, that is a reasonable moment to reconsider the provider.

3. Check whether you depended on OCSP-delivered SCTs

If the error appeared suddenly in 2026 on an unchanged server, this is the first thing to test. Chrome 148 no longer accepts SCTs delivered in a stapled OCSP response, so a setup that met the policy that way now fails, while the same site continues to work in older Chrome builds and in other browsers. Chrome’s own developer tools will show the connection failing on certificate verification while everything else about the server looks normal.

The remedy is the same reissue described above: get the SCTs embedded in the certificate, which removes the dependency on any server-side delivery mechanism.

4. Check the status of the logs your SCTs came from

Logs are added, retired, and removed over time. If your certificate’s SCTs came from logs that Chrome has since stopped recognizing, or were issued after a log’s Retired timestamp, the count Chrome arrives at can be lower than the number of receipts you see in the certificate. Compare the Log IDs from the output above against Chrome’s current log list, and if any of them no longer qualify, ask your CA for a reissue against currently recognized logs.

5. For internal hosts, check what root you are chaining to

Certificate Transparency applies only to publicly trusted CAs. A certificate that chains to a private or manually installed root is exempt from the policy entirely, so an internal server, a lab appliance, or a device on your own network should never produce this error.

If an internal host does show it, the certificate is chaining to a publicly trusted root rather than to your internal CA, and that is the thing to correct. Conversely, if your private root is not installed on the client, Chrome complains about the issuer instead and returns NET::ERR_CERT_AUTHORITY_INVALID, which is a different problem with a different fix.

Can you keep a domain out of the CT logs?

Not for a publicly trusted certificate. Advice to ask your CA to skip CT logging for privacy reasons circulates widely, and it is out of date: the Chrome Root Program now requires CA owners to log all TLS precertificates before issuance, with no privacy exemption. A CA that agreed to skip logging would be issuing a certificate that Chrome refuses, which is exactly the error this page is about.

If the concern is that CT logs publish your hostnames, and internal names like vpn.example.com or staging.example.com become searchable, there are two supported approaches:

• Use a wildcard certificate. The log records *.example.com, so the individual subdomain labels never appear in a public log.
• Use private PKI for hosts that do not need to be reachable by the public. Certificates from your own internal CA are not publicly trusted, are not logged, and are not subject to CT at all.

Treating public hostnames as secret is not a durable strategy in any case, since CT logs are only one of many places names surface. Keeping private services on private PKI, behind access controls, is the approach that holds.

A note on the enterprise CT exception policies

Chrome has enterprise policies that suppress CT enforcement, and they are frequently suggested as a fix for this error. They are almost never the right answer, for a reason worth being explicit about: they only apply to browsers your organization administers. They change nothing for the general public, so if the site is public-facing, the error continues for every visitor while looking resolved on your own managed machines.

Two policies remain: CertificateTransparencyEnforcementDisabledForUrls, which exempts specific URLs, and CertificateTransparencyEnforcementDisabledForCas, which exempts certificates under specified CA public key hashes. A third, CertificateTransparencyEnforcementDisabledForLegacyCas, was removed in Chrome 128 and no longer does anything.

Both turn off the check that detects misissued certificates for the hosts they cover, which is the entire point of Certificate Transparency. Reserve them for a managed internal system you cannot reissue for, treat them as temporary, and fix the certificate rather than the browser wherever you can.

If you are a visitor, not the site owner

There is no client-side fix, and it is worth saying plainly because so much troubleshooting advice suggests otherwise. Clearing your browser cache, clearing the SSL state through inetcpl.cpl in Windows, and disabling extensions all leave certificate verification untouched, so none of them can change this outcome. The Windows SSL state in particular belongs to Schannel, the system TLS stack, which Chrome does not use for this check.

One step is genuinely worth taking, though not for the reason usually given. Make sure Chrome is current:

chrome://settings/help

Paste that into the address bar and press Enter, and Chrome checks for updates. The point is not that an old Chrome is stricter about CT. It is the opposite: Chrome relies on a list of recognized logs that it updates separately from the browser itself, and if the freshest list it holds is more than 70 days old, Chrome stops enforcing CT altogether. A stale browser therefore enforces less, not more. What an outdated Chrome can do is fail to recognize a log that qualified recently, which lowers the SCT count for a certificate that is genuinely compliant. Updating fixes that specific case.

If the error persists on a current Chrome, the certificate is at fault. Report it to the site owner, and do not click through such a warning on a site where you enter credentials or payment details.

Chrome, Firefox, and Safari all enforce CT

The NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED string is specific to Chrome and other Chromium-based browsers such as Edge, Brave, and Opera. The underlying requirement is not.

• Firefox has enforced CT since version 135 on desktop, released in February 2025, and since version 145 on Android. Its error is MOZILLA_PKIX_ERROR_INSUFFICIENT_CERTIFICATE_TRANSPARENCY.
• Apple has enforced its own CT policy since iOS 12.1.1 and macOS 10.14.2 in 2018, and it applies across the operating system rather than only in Safari, so apps fail the same way.

A certificate with insufficient CT proof is therefore broken everywhere, not only in Chrome. If a site loads in one browser and not another, the usual explanation is a difference in versions or in policy timing rather than one browser being wrong.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.