Embedded SCT count (Certificate Transparency)

TL;DR: Every TLS certificate has to be logged to public, append-only Certificate Transparency logs before browsers will trust it. Each log signs a receipt — a Signed Certificate Timestamp (SCT) — and most CAs embed two or three of those receipts directly in the cert at issuance. Browsers (Chrome since 2018, Apple/Mozilla similar) require at least two SCTs from independent logs before a cert is trusted. This almost always just works — but when it doesn’t, the fix is your CA’s, not yours.

What is it?

Certificate Transparency (CT) is a public-good system that makes every TLS certificate ever issued visible to anyone who wants to look. It’s run by independent operators — Google, Cloudflare, DigiCert, Sectigo, Apple, Let’s Encrypt itself — each of whom operates one or more CT logs. A CT log is an append-only ledger: certs go in, nothing ever comes out, and the contents are cryptographically chained so you can’t quietly rewrite history.

When a CA issues a cert, they submit it to multiple CT logs operated by different parties. Each log signs a short receipt that says, in effect, “I have this cert in my log, here’s the timestamp, and here’s a signature you can verify against my public key.” That signed receipt is a Signed Certificate Timestamp, or SCT.

Most CAs embed those SCTs directly in the certificate they issue to you — usually two or three of them, from independently operated logs. When your server presents the cert during a TLS handshake, the browser pulls the SCTs out, verifies the signatures against the public CT log keys it knows about, and treats the cert as trustable only if enough independent receipts check out.

Why does it matter?

CT was born after the DigiNotar (2011) and TURKTRUST (2013) mis-issuance scandals. In both cases, bad actors at trusted CAs issued fraudulent certificates for high-value domains — including, in the DigiNotar case, a wildcard cert for *.google.com used to intercept Iranian Gmail traffic. Nobody noticed for months. The certs were trusted; the chain of trust held; the public web had no way to see what had been issued.

CT closes that gap by making every issuance observable. Anyone — the actual domain owner, a security researcher, a competing CA, a journalist — can search the public CT logs and see every cert that’s ever been issued for a given name. If a CA mis-issues a cert for your domain tomorrow, you can find out the same day, not six months later.

To make CT actually load-bearing, browsers enforce it on the client side. Chrome requires ≥ 2 SCTs from independent logs as a precondition to trusting a cert (since 2018); Apple and Mozilla adopted equivalent policies around the same time. Without enough SCTs, your cert isn’t trusted — full stop.

Real-world analogy

Think of SCTs as notarization stamps from independent registries on your certificate. Each stamp says: “yes, we saw this cert get issued, and here’s a receipt.” Two stamps from different notaries means at least two independent witnesses observed the issuance — which makes it much harder for a rogue CA employee (or a compromised CA) to quietly mint a fraudulent cert without anyone noticing. The browser is the careful counterparty that won’t accept the certificate unless the notary stamps check out.

Three ways SCTs reach the browser

The CT spec actually defines three delivery channels for SCTs. You only need one to satisfy the browser, but it’s useful to know all three exist:

Embedded in the cert (most common). The CA includes the SCTs as an X.509 extension on the leaf certificate at issuance time. The OID for that extension is 1.3.6.1.4.1.11129.2.4.2. This is by far the most reliable path — the SCTs travel with the cert no matter what — and is how essentially every modern public CA handles CT.
Via OCSP staple. The CA can deliver SCTs in the OCSP response, and your server can staple that response to the handshake (see OCSP stapling, WEBQ-91). This works but depends on stapling being configured correctly and the CA actually returning SCTs in their OCSP responses.
Via TLS extension at handshake time. The signed_certificate_timestamp extension (RFC 6962 §3.3.1) lets the server return SCTs directly in the TLS handshake. Almost no one uses this in practice.

WEBQ-92 looks at the embedded path because it’s the static, observable one — we can see it just by parsing the cert bytes, without needing to negotiate anything with the server. If your CA delivers SCTs only via OCSP or TLS extension, the cert may still be trusted by browsers, but the embedded signal is missing and we score it accordingly.

How WQI measures this

We grade embedded SCTs as factor WEBQ-92 in the Security category. The data source is the leaf certificate ASN.1 — we count extensions matching the SCT extension OID 1.3.6.1.4.1.11129.2.4.2, surfaced by the TLS prober.

Today this is a presence-only check (0 or 1+ embedded SCTs). A future version will parse the SCT list itself to count individual entries and verify they come from independent log operators — that’s the bar browsers actually enforce. For now, presence of the extension is a strong proxy: every modern public CA that embeds at all embeds at least two from independent logs.

Result	What it means
Pass (100)	≥ 2 SCTs embedded — meets browser CT compliance bar.
Warn (60)	Exactly 1 SCT embedded — under bar; cert may be flagged on some clients.
Fail (0)	0 SCTs embedded — cert may still be trusted via OCSP or TLS-extension delivery, but the static signal is missing.

What good looks like

Pass on WEBQ-92 — which means at least two SCTs from independent logs embedded directly in your cert. For any cert issued by a mainstream public CA in 2026, this happens automatically: the CA logs to multiple CT logs at issuance, collects the SCTs, and embeds them before handing the cert to you. You don’t configure this and you don’t pay extra for it. It just works.

How to fix it

Almost always your CA’s responsibility — re-issue the cert and you should get the modern embedded-SCT count automatically. If you’re seeing 0 or 1 embedded SCTs from a public CA in 2026, something’s wrong on their side; contact CA support and request reissue. This is uncommon enough that the fix is usually a support ticket, not a config change.

A few specific cases to be aware of:

Private or internal CAs. Enterprise PKI, dev/staging internal CAs, and homelab roots typically don’t log to CT — partly because the public CT logs would expose internal hostnames, and partly because there’s no browser policy requiring it for non-publicly-trusted certs. For internal-only certs, this factor isn’t applicable, and “fail” is the expected reading.
Self-signed certs. Same story. Not logged, not applicable.
Cloudflare-issued / origin certs not visible to the web. Cloudflare’s edge certs (the ones browsers see) are public-CA certs and have embedded SCTs. The “origin certs” Cloudflare issues for the link from their edge to your origin server are not publicly trusted and don’t carry CT proofs — that’s by design and only matters between Cloudflare and your server, not browsers.

Going further: how to look up your domain in CT

Because CT logs are public, you can look up every cert ever issued for your domain. The standard tool is crt.sh:

https://crt.sh/?q=yourdomain.com

That returns the full history — every cert across every public CT log, with issuer, validity dates, SAN list, and links into the underlying logs. It’s an extremely useful audit tool:

Spot certs you didn’t authorize (a reasonable first sign of CA mis-issuance or a compromised internal cert provisioning flow).
Verify a CA actually logged a cert it told you it issued.
Track historical cert hygiene — multi-year wildcards, abandoned subdomains, etc.

For programmatic access, Censys (censys.io) and Google’s CT search (transparencyreport.google.com/https/certificates) offer richer queryable interfaces. You can also subscribe to real-time CT log feeds and get alerted whenever a new cert is issued for your domains — useful for security teams running larger property portfolios.