# NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED: missing CT proof

> NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED means the certificate lacks valid Certificate Transparency SCTs required by Chrome. Causes and fixes.

Source: https://ssl.sh/errors/err-cert-transparency-required/
Last updated: 2026-11-10

**NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED means the certificate is from a public CA but Chrome could not find proof that it was publicly logged.** Certificate Transparency (CT) requires every publicly trusted certificate to be recorded in public logs, so that mis-issued certificates are visible. A certificate without valid proof is rejected.

## Is it the site or your device?

Usually the certificate is defective; if it is not, something on your network is replacing it. Check with the [SSL checker](https://ssl.sh/tools/ssl-checker/), which shows the embedded SCTs:

```bash
curl ssl.sh/example.com
```

- **The checker reports missing or invalid SCTs:** the certificate is defective. The site must replace it, usually by asking the CA to reissue.
- **The checker shows valid SCTs:** something on your network is presenting a different certificate that chains to a public root but was never logged. That is a serious red flag; do not continue, and try another network.

## Causes

### 1. CA issued the certificate without SCTs

Issuance without SCTs is rare with mainstream CAs, but it happens with misconfigured issuance pipelines or certificates issued through unusual channels. Check the certificate for the "CT Precertificate SCTs" extension:

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

No output means no embedded SCTs.

### 2. Not enough SCTs, or SCTs from unqualified logs

Chrome's policy requires a minimum number of SCTs from logs it currently accepts, and the number depends on the certificate's lifetime. A certificate logged only in logs Chrome does not recognise fails.

### 3. Interception with a publicly chained certificate

A proxy that somehow has a publicly trusted intermediate would produce certificates without SCTs. Chrome blocks this precisely to expose such misuse.

### 4. Clock far in the past

If your device clock is behind the SCT timestamps, the proofs appear to come from the future. Fix the time.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge | "Your connection is not private" with `NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED` |
| Safari | "This Connection Is Not Private"; Apple platforms enforce their own CT policy |
| Firefox | Recent desktop versions have begun enforcing CT; older versions load the page |

## How site owners fix it

A reissued certificate with embedded SCTs from qualified logs fixes it.

**1. Look the certificate up in CT logs.** Use [CT search](https://ssl.sh/tools/ct-search/) with your domain; if the certificate is not there, it was never logged.

**2. Ask the CA to reissue** a certificate with embedded SCTs, or switch to an ACME CA. All mainstream public CAs embed SCTs by default:

```bash
sudo certbot certonly --nginx -d example.com --force-renewal
```

**3. Deploy and verify.** Reload the server, then check with `curl ssl.sh/example.com` and the [certificate decoder](https://ssl.sh/tools/certificate-decoder/) that the SCT extension is present.

**4. For internal hostnames** that chain to a private root, nothing is needed. If a public-chained internal certificate must be exempted temporarily, use the enterprise policy rather than asking users to change settings. Background: [Certificate Transparency](https://ssl.sh/learn/certificate-transparency/).