Certificate transparency explained: the public logs and the certificate you did not order

What certificate transparency is

For most of the web's life a certificate authority could issue a certificate for any name to anyone who passed its checks, and nobody but the two parties would know. When an authority was tricked or broken into, as DigiNotar was in 2011, the certificates it issued for other people's domains were found by accident, in use, weeks later. Certificate transparency (RFC 6962, revised as RFC 9162) closes that gap. Every publicly trusted certificate is submitted to public, append-only logs when it is issued, and each log returns a signed timestamp that is presented alongside the certificate, usually embedded in it. Chrome has refused certificates without those timestamps since 2018 and Apple's platforms have required the same since late that year, so a public certificate that is not in the logs does not work in the major browsers.

The logs are built as Merkle trees, so anyone can prove an entry is present and that nothing already written has been altered. For a domain owner the consequence is simpler than the machinery. Every certificate any public authority issues for your names is on the record by the time it is used, whether you ordered it or not, and a record can be read.

Searching the logs

The logs themselves are for machines: each is a stream of entries fetched by index, in the order they were written. Asking them a question by name, such as every certificate ever issued for a domain, takes a search that has read the logs and indexed what it found. Public searches of that kind come and go, so treat any one of them as a convenience rather than a fixture. If you query one, be gentle with it: one query when you need one, never a loop.

Three quirks show up whichever you read. A certificate usually appears twice, once as the precertificate the authority logged before issuing and once as the final certificate, with the same serial number under two different log entries. A busy name's list runs to thousands of entries going back years, because a log never forgets. And an entry can turn up late: an old certificate that surfaces after it has already expired is history.

Why a certificate you did not order matters

Whoever holds a certificate for your domain, and can steer traffic to themselves through a DNS change, a compromised network or a hosting account, can serve a site that claims to be yours, and every browser will agree that it is. It happens in a few ways.

Somebody else passed domain validation. An attacker with control of your DNS, or of a path on your web server, can answer the challenge an authority sets. The certificate is the first thing they obtain and often the first evidence anyone sees.

An authority mis-issued. Rare now, and the reason transparency exists.

A colleague or a vendor ordered one. A marketing site on a new host, a product that terminates TLS for a subdomain you pointed at it. Legitimate, and still worth knowing about, because a third party now holds a key for a name of yours.

A look-alike does not show up here. A certificate for a misspelt copy of your domain is in the logs under that name, and no search for your own domain finds it.

When an unexpected certificate appears, the issuing authority is named in the entry, and an authority must revoke a certificate the domain's holder did not authorise. Then find the hole: check who has access to your DNS and your CA account.

Telling your own certificates from the rest

The useful question about any certificate in the logs is whether it is yours. Its serial number and issuer answer that. Compare them with the certificate each of your hosts is serving:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -serial -issuer

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

The first command prints the serial number and issuer of the certificate your host is serving right now. The second prints the signed certificate timestamps embedded in that same certificate, one for each log that recorded it, with the time it did. That needs OpenSSL 1.1 or later, and a certificate that carries its timestamps inside it, as most public ones do. The SSL checker reads the same certificate from outside, with its fingerprint, days left, the names it covers and whether the chain and hostname check out.

A match between a log entry and a served certificate is a renewal that has landed. No match is a certificate somebody else holds, or one of yours that is not live yet, and either way worth a look.

That comparison is only as good as your knowledge of what each host serves today. A certificate monitor keeps it current: it reads the certificate each host serves on a schedule and alerts when the fingerprint or issuer changes, as expiry comes near, and when the certificate stops covering the hostname or its chain stops validating.

Subdomains

A search for example.com can cover everything under it as well, and that is where the surprises live: a certificate for a hostname you forgot, a staging host someone gave a real certificate, a vendor subdomain that still resolves.

The same openness cuts the other way. Every hostname you have ever put on a public certificate is readable by anyone, forever, which is why internal names belong under a wildcard certificate or a private authority and out of the public record.