Certificate Transparency: A Public Provenance Log for TLS

01 /What certificate transparency is

Certificate transparency is a public record of TLS certificate issuance. Before CT, any of several hundred publicly trusted certificate authorities could issue for any name, and the domain owner learned of it only if someone noticed it in use. The DigiNotar breach of 2011 showed the gap. CT closes it: a certificate must be logged publicly before browsers will trust it.

RFC 6962, published in 2013 as experimental, defined version 1. RFC 9162, published in December 2021, defines version 2 and obsoletes it. The model is the same: independent operators run logs, each an append-only list of certificates organised as a Merkle hash tree with a signed tree head. Anyone can fetch entries and check that the tree only grows. In the terms of the network-layer provenance lane at FoundryNet, a CT log is a public ledger of who vouched for which name, and when.

02 /How a log and an SCT work

A CA submits a certificate, or more often a precertificate, to several logs at issuance. RFC 9162 Section 4 describes the log as a Merkle tree whose leaves are the entries and whose root hash changes with every append. An inclusion proof shows that one leaf is under a given root; a consistency proof shows that a newer tree contains the older one unchanged. Together they let an auditor confirm the log has not rewritten history.

The log's immediate answer is a Signed Certificate Timestamp: a signature by the log's key over the certificate and a timestamp, promising inclusion within the log's Maximum Merge Delay, commonly 24 hours. The browser checks the SCT at connection time; auditors later check that the promise was kept. A precertificate is the certificate with a poison extension that makes it unusable; the CA logs it, collects SCTs, then issues the final certificate with them embedded.

03 /How SCTs reach the browser

Both RFCs define three delivery methods. Embedded: an X.509 extension inside the certificate. TLS extension: sent in the handshake, as signed_certificate_timestamp under RFC 6962 or transparency_info under RFC 9162. OCSP stapling: carried in the stapled response. The last two need configuration on every server that terminates TLS.

Browser policy decides how many SCTs are enough. The Chrome Certificate Transparency Policy requires SCTs on every publicly trusted certificate issued since 30 April 2018: for embedded SCTs, at least one from a log qualified at validation time, two in total for certificates valid 180 days or less, three for longer, from more than one log operator. SCTs must currently come from RFC 6962 logs; version 2 logs are not yet in browser trust lists. Apple's policy uses the same 180 day boundary.

04 /What CT proves and what it does not

CT proves that a certificate was logged: which logs accepted it, when, and that the record has not since been altered. From that, a domain owner can discover every certificate any CA has issued for their names, requested or not. CT does not stop a CA from issuing. A compromised CA can still mint a certificate for example.com; logging makes the act visible, but the certificate is valid in every browser until revoked. CT proves nothing about the private key or the bytes served under the certificate, the question covered under TLS, digests and subresource integrity. And CT is only a promise unless someone audits the logs; for your own domains, that is you.

05 /CT versus CAA, OCSP, CRL and pinning

RFC 8659 pairs naturally with CT. A record such as example.com. IN CAA 0 issue "ca.example.net" tells every other CA to refuse issuance for that name, and CA industry rules require the check. CT then shows whether it was honoured; a logged certificate from an excluded CA is the CA's incident, and the log entry is your evidence.

06 /Checking SCTs at the edge

In most estates the certificate is presented by a balancer or reverse proxy, because TLS termination happens on the layer 7 device, not the real servers. That device is where the SCTs must be and where you check them. A certificate renewed by an automated client almost always carries embedded SCTs; one installed by hand may not. OpenSSL prints the list from what the balancer serves.

$ openssl s_client -connect 203.0.113.10:443 -servername www.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -text | grep -A 12 'CT Precertificate SCTs'
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12:
                                ED:90:37:7F:1F:85:6A:EB:C1:BF:2E:1C:B2:6F:C7:BF
                    Timestamp : Sep 21 09:14:03.512 2026 GMT
                Signed Certificate Timestamp:
                    Timestamp : Sep 21 09:14:03.601 2026 GMT
$ curl -s https://ct.example.net/ct/v1/get-sth
{"tree_size":1184402117,"timestamp":1790241612345,...}

Two SCTs from two log IDs is the minimum Chrome accepts for a 90 day certificate. The second command uses the RFC 6962 log API: get-sth returns the signed tree head, get-entries leaves by index, get-proof-by-hash an inclusion proof. On a pool built as the virtual server and real server pool guide describes, check every virtual IP; one stale copy breaks a site.

07 /Worked example: monitoring one domain

Take a company that owns example.com, terminates TLS on two balancers, and renews through an automated client against one CA. The question is: which certificates exist for our names, and did we ask for each? First, write down the expected state: the names (example.com, www, mail, a staging wildcard), the issuing CA, the renewal cadence (every 60 days for 90 day certificates) and the key fingerprints. Publish CAA records naming that CA with issue and issuewild tags and an iodef address. Second, run a monitor: a job that fetches new entries from each log in the browser trust lists, or a CT search service that does so, and matches Subject Alternative Names against your names. Third, reconcile every match against the renewal client's request log; a match without a request is an alert.

In a typical year the monitor sees six to eight expected certificates per name, plus a few surprises that are almost always internal: a developer's test host from another CA, or a vendor's redirect certificate. An unknown CA issuing for a production name is the rare case the job exists for. The entry (log ID, leaf index, timestamp, certificate) is retained as evidence, as tamper-evident edge logging retains a request record.

When the monitor reports a certificate you did not request, act in this order. Confirm it is unexpected: check renewal history and vendors that issue on your behalf. Record the log, index and SCT timestamps. Report it to the issuing CA's problem address; the CA must investigate and revoke within a fixed window if mis-issuance is confirmed. If the private key could be yours, rotate every certificate that used it. Review CAA and DNS control, since most mis-issuance now traces to validation weaknesses. The edge-to-origin leg is separate: the private CA and client certificate design there ignores public certificates entirely.

08 /Pitfalls

• Treating CT as prevention. A logged certificate is valid until revoked. Without a monitor, CT gives you nothing.
• Hand-installed certificates without SCTs. A certificate copied from an old appliance may carry no SCTs and fails Chrome's policy. Check what the balancer serves.
• Leaking internal names. Every SAN in a public certificate is searchable forever. Keep vpn-backup.corp.example.com out of them; use a wildcard or a private CA.
• Assuming CAA covers a hijacked zone. An attacker who controls your DNS can change the CAA record and pass validation. CAA constrains honest CAs; it does not protect the zone.

Two related checks sit beside this one: a validating resolver checking the signature on a DNS answer protects the name lookup that precedes every TLS handshake, and signatures on firmware images and configuration bundles apply the same public-key reasoning to the software your edge runs.

Certificate transparency is the one place on the public internet where issuance of a name is recorded before it can be used. Read it as a public provenance log of who vouched for which name, one you are expected to audit for your own domains. Publish CAA, check SCTs on your balancers, and run a monitor.