Certificate Transparency

Your browser trusts dozens of certificate authorities, and any one of them can issue a certificate for any name, including yours. Normally a CA only does that after checking that the requester controls the name (see Proving you own the name). But a CA can make a mistake, be tricked or be broken into. Before Certificate Transparency, the real owner of a name had no way to find out. A certificate issued in secret could be used in secret.

Certificate Transparency (CT) removes the secrecy. Every publicly trusted certificate is recorded in public CT logs that anyone can read. The logs are append-only: entries cannot be quietly changed or removed, because anyone can check that today’s log still contains yesterday’s. Browsers refuse certificates that do not come with proof that they were logged.

That proof is a signed certificate timestamp (SCT): a log’s signed promise that it will record this certificate. The CA collects the SCTs before it hands over the certificate, and usually puts them inside it.

Logging alone protects nobody. Someone has to read the logs. That is the job of a monitor: a program or service that watches the logs for the names you care about and tells you when a new certificate appears. If you find a certificate for your domain that nobody in your organisation asked for, you can ask the CA to revoke it (see Revocation) and find out how it happened.

So CT does not stop a bad certificate from being issued. It makes sure that a bad certificate cannot be used against browsers that enforce CT without first appearing in public logs. That changes behaviour: CAs know that everything they sign will be seen, and browsers can judge each CA on its public record.

What is a CT log?

CT is specified in RFC 6962 (version 1) and RFC 9162 (version 2). Both are Experimental RFCs, so in practice the browsers’ log policies decide which logs count. RFC 6962 section 3 describes a log as “a single, ever-growing, append-only Merkle Tree” of certificates.

A Merkle tree hashes every entry, then hashes pairs of hashes, up to a single root hash (section 2.1). The log signs that root together with the tree size and a timestamp. The result is the signed tree head. Two short proofs follow from this structure:

• an inclusion proof (an audit path) shows that one certificate is in the tree, using only a handful of hashes;
• a consistency proof shows that a newer tree still contains the older tree, unchanged. This is what makes “append-only” something anyone can check rather than a promise.

Swipe sideways to see the whole diagram.

Anyone can ask a log for its current signed tree head (section 4.3). This is the real answer from Google’s Xenon2026h2 log in October 2026:

curl -s https://ct.googleapis.com/logs/eu1/xenon2026h2/ct/v1/get-sth

{"tree_size":2978650224,"timestamp":1792448277892,"sha256_root_hash":"sjiOlYWWqSWr+YPhZx6orcW4YkVpOAvx9aGuw36QlUQ=","tree_head_signature":"BAMARjBEAiBGrqe3FNfZis8d7dBeN2NYYNWl9Ccb8fRPhspm15TZZQIgPnLOP7ORFFCXlOAcdk8O1rl2XKBWabVur1vmJl8UBJs="}

That single 32-byte root hash, signed by the log, stands for almost three billion entries.

What is an SCT, and how does it reach the browser?

When a certificate is submitted, “the log MUST immediately return a Signed Certificate Timestamp (SCT)”. RFC 6962 calls the SCT “the log’s promise to incorporate the certificate in the Merkle Tree within a fixed amount of time known as the Maximum Merge Delay”. The SCT is a promise, not proof of inclusion; the inclusion proof is the evidence.

To put SCTs inside the certificate itself, the CA first logs a precertificate: a copy of the final certificate made unusable by a critical “poison” extension (section 3.1). The logs return SCTs for it, the CA adds them to the certificate as an extension, and only then signs the real certificate. Section 3.3 allows two other ways to deliver SCTs: in a TLS extension sent by the server, or inside a stapled OCSP response. Embedded SCTs need no change on the server at all.

Swipe sideways to see the whole diagram.

What do browsers require?

Chrome requires Certificate Transparency for publicly trusted TLS certificates (since April 2018). For SCTs embedded in the certificate, Chrome’s CT policy asks for SCTs from at least two different logs for certificates valid for 180 days or less, and three for longer ones, with at least two different log operators. A certificate that does not comply “will simply fail to validate”, and Chrome shows NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

Apple platforms require Certificate Transparency for publicly trusted TLS certificates, with similar SCT counts (Apple’s policy). Firefox enforces Certificate Transparency on desktop platforms from Firefox 135 onwards (Mozilla), and a failing site shows MOZILLA_PKIX_ERROR_INSUFFICIENT_CERTIFICATE_TRANSPARENCY.

These rules cover publicly trusted certificates only. Chrome’s policy speaks of “publicly-trusted TLS certificates”, and Firefox enforces CT for roots in Mozilla’s root program. A certificate from your own private CA, whose root you installed yourself, is not checked for SCTs.

Browsers also publish which logs they accept. Chrome’s log list names each log, its operator and its state. It now holds both classic RFC 6962 logs and newer “tiled” logs, which publish their data as static files.

Who checks the logs?

RFC 6962 section 5 names three roles besides the CA that submits:

• TLS clients (section 5.2) check SCTs during the handshake.
• Monitors (section 5.3) “watch logs and check that they behave correctly. They also watch for certificates of interest.” A monitor must at least inspect every new entry in each log it watches.
• Auditors (section 5.4) take partial views of a log and check that they agree, using consistency proofs between tree heads and inclusion proofs for SCTs.

In practice, CAs, browser makers, researchers and commercial services run monitors, and free public search sites such as crt.sh let anyone look up a name by hand.

What does CT not do?

• It does not prevent issuance. A rogue certificate gets its SCTs like any other. To limit which CAs may issue for your names, publish CAA records (see Proving you own the name).
• It does not judge intent. A properly validated certificate for a lookalike phishing domain is logged like any other, and a search for your exact name will not find it.
• It only helps if someone reads it. A certificate that nobody looks for stays unnoticed.
• It only protects clients that check SCTs. Browsers enforce CT, but most other TLS clients, such as curl, Java and Python libraries, do not check SCTs by default. An unlogged certificate could still fool them.
• It does not cover private CAs. Certificates from your own CA are not in public logs, and should not be.
• It publishes names. Every name in a publicly trusted certificate becomes public, including internal host names.

Does my certificate carry SCTs?

OpenSSL prints the embedded SCTs. This is the start of the real output for the letsencrypt.org certificate:

openssl x509 -in cert.pem -noout -ext ct_precert_scts

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 : Sep  4 15:33:02.377 2026 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256

A second SCT block follows. Matching the two Log IDs against Chrome’s log list shows that they come from two different operators: Google’s Xenon2026h2 log and Geomys’s Tuscolo2026h2 log. That is what the policy asks of a certificate with this lifetime. If the command prints nothing, the certificate has no embedded SCTs: it comes from a private CA, or it relies on SCTs delivered in the handshake.

Paste a certificate into the decoder to see its extensions:

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

How do I look up certificates for my names?

Search the logs by hand on crt.sh: open https://crt.sh/?q=example.com in a browser, with your own domain. A JSON version suits scripts:

curl -s "https://crt.sh/?q=example.com&output=json"

crt.sh is a free public service and is often overloaded. While we wrote this chapter, it answered our queries with 502 Bad Gateway several times in a row. Use it for manual checks and investigations, not as your only alarm. For continuous watching, use a monitoring service, your CA’s tools or your certificate management platform, and make sure alerts reach a person.

What should I look for?

• Issuers you do not use. If your organisation buys from one or two CAs, a certificate from a third deserves a question.
• Names you do not recognise, especially wildcards and forgotten subdomains.
• Certificates nobody remembers ordering, for example when no renewal was due.

Most surprises turn out to be innocent: a team that put a subdomain behind a SaaS provider or a content delivery network, which then obtained a certificate for it, or a forgotten test server. Check internally before you escalate.

What do I do with a certificate that is not ours?

1. Save the evidence: the crt.sh link or the certificate itself, with its serial number and issuer.
2. Report it to the issuing CA. The Baseline Requirements (section 4.9.3) oblige every publicly trusted CA to publish clear instructions for reporting misuse and to accept reports around the clock. The CA must investigate. If the validation cannot be relied on, it must revoke within 24 hours.
3. Find out how validation was passed. Look at your DNS records, web servers and registrar and DNS-provider accounts.
4. Tighten CAA records so that only the CAs you use may issue for your names.

What does CT reveal about us?

Every name in a publicly trusted certificate appears in public logs, before the certificate even reaches you, because the CA logs the precertificate first. A certificate for vpn-test.internal.example.com tells the world that the host exists. Do not rely on secret host names for security. For services that only your own staff and systems use, issue certificates from a private CA instead (see A CA of your own). A wildcard certificate hides individual names, but every server that holds its key can impersonate every name it covers, so weigh that trade-off carefully.

If Chrome shows NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, the certificate chains to a publicly trusted root but lacks valid SCTs. You cannot fix this on the client. Ask the CA to issue a properly logged certificate.

Common mistakes

• “CT prevents mis-issuance.” It makes mis-issuance visible. Validation and CAA records are what limit issuance.
• “An SCT proves the certificate is in the log.” It is a signed promise. The inclusion proof is the evidence.
• “CT is only for big companies.” Every publicly trusted certificate for your names is already in the logs, and anyone can search them for free.
• “Our internal host names are secret.” Not if they appear in a publicly trusted certificate.
• “Certificates from our private CA must be logged.” Browsers do not require CT for private roots, and logging would publish internal names.

Check yourself

Check yourself

A CA you have never used issued a certificate for your domain. What did Certificate Transparency do?

1. It blocked the certificate before it was issued
2. It made the certificate publicly visible so you can find it, report it and get it revoked
3. Nothing, because CT only covers EV certificates

Show answer

Answer B It made the certificate publicly visible so you can find it, report it and get it revoked

What happened

The certificate was logged and became visible to anyone watching your names.

Why

CT logs every publicly trusted TLS certificate, but it does not decide whether a certificate should exist.

The rule

CT makes mis-issuance detectable. It does not prevent it.

Check yourself

What is a signed certificate timestamp (SCT)?

1. A CT log's signed promise to add the certificate to the log
2. Proof that the certificate has not been revoked
3. The CA's own signature over the certificate

Show answer

Answer A A CT log's signed promise to add the certificate to the log

What happened

An SCT is returned by a log when a certificate or precertificate is submitted.

Why

Browsers require SCTs as evidence that a certificate was submitted to logs they accept.

The rule

An SCT is a promise. Inclusion proofs show the certificate really is in the log.

Check yourself

You put an internal host name in a publicly trusted certificate. Who can see that name?

1. Only the issuing CA
2. Anyone who searches Certificate Transparency logs
3. Nobody, because CT logs store only hashes

Show answer

Answer B Anyone who searches Certificate Transparency logs

What happened

The full certificate, including every name in it, is published in the logs.

Why

Logs store whole certificates so that monitors can check every name.

The rule

Names in public certificates are public. Use a private CA for internal-only names.

Go deeper

• RFC 6962: Certificate Transparency version 1, the version the browsers’ log policies are built on.
• RFC 9162: Certificate Transparency version 2.0, which obsoletes RFC 6962.
• Chrome’s CT policy: how many SCTs Chrome requires and from which logs.
• Chrome’s CT log lists: the logs Chrome accepts and their states.
• Apple’s CT policy: the requirements on Apple platforms.
• Mozilla: Certificate Transparency: how and since when Firefox enforces CT.
• CA/Browser Forum Baseline Requirements, section 4.9.3: how CAs must accept problem reports.

In the gameLevel 17: Everyone can seePublic Ledger Hall, Keystone. In development

The crash course covers Certificate Transparency in lesson 8, When trust breaks.