Every publicly-trusted TLS certificate issued since roughly 2018 has been recorded in a public, append-only, cryptographically verifiable log. This system is called Certificate Transparency (CT), and it was designed to catch rogue or mis-issued certificates.

In this post I will briefly cover how CT works, and some clever alternative uses for it.

What is Certificate Transparency?

CT was introduced by Google in RFC 6962 after a series of high-profile CA compromises (DigiNotar in 2011, Trustwave debacle in 2012). The idea is simple: before a CA issues a certificate, it must submit the certificate to one or more public logs. The log will return a Signed Certificate Timestamp, which is then embedded in the certificate as proof that it was logged. All major browsers enforce CT - if a certificate doesn’t carry valid SCTs, the browser will reject it.

The logs themselves are Merkle trees. The tree structure allows anyone to cryptographically verify that:

  • A specific certificate is included in the log
  • The log has not tampered with or removed entries

This effectively means that CAs can’t quietly issue a certificate for entities they do not control and hope nobody notices. Everything they issue gets logged for the entire world to see, and there are teams around the world keeping a close eye.

The log ecosystem

There are a ton of CT logs operated by organisations like Google, Cloudflare, DigiCert, Let’s Encrypt and others. Google and Apple each maintain authoritative lists of which logs their browsers trust.

Google’s list:

https://www.gstatic.com/ct/log_list/v3/log_list.json

Apple’s list:

https://valid.apple.com/ct/log_list/current_log_list.json

Google’s list is more widely used, for example it is compiled into weekly Firefox builds. As such, I’ll focus on that.

Each log entry in Google’s JSON looks something like this:

{
  "description": "Google 'Argon2026h1' log",
  "log_id": "<base64>",
  "key": "<base64 DER-encoded SubjectPublicKeyInfo>",
  "url": "https://ct.googleapis.com/logs/us1/argon2026h1/",
  "mmd": 86400,
  "state": { "usable": { "timestamp": "..." } },
  "temporal_interval": {
    "start_inclusive": "2026-01-01T00:00:00Z",
    "end_exclusive": "2026-07-01T00:00:00Z"
  }
}

The url field points to the base URL for the log’s API.

The CT log API

Every CT log exposes the same REST API, defined in RFC 6962. The two endpoints you care about for monitoring purposes are:

Getting the tree head

GET <log_url>/ct/v1/get-sth

https://ct.googleapis.com/logs/us1/argon2026h1/ct/v1/get-sth

Which returns the current state of the log:

{
  "tree_size": 2148452383,
  "timestamp": 1771118735433,
  "sha256_root_hash": "98SmR6Q4mDxH7mbPw0ijuPeCsOOhV9zHdBj/5cgabP4=",
  "tree_head_signature": "BAMARzBFAiEAxkMiGKD9q84sP1xHRo3m/YSsXe7AG8L1AGwJSLYUhNQCIEQuz24NcJ4v+tYtRXAcNw5WzzMLjcdocwESMsKUmm/M"
}

tree_size is the total number of entries in the log. This is our starting point if our goal is to monitor a log for new certificates. The loop is basically: note the current tree_size, wait, fetch it again, and then pull the new entries in between.

Fetching entries

GET <log_url>/ct/v1/get-entries?start=X&end=Y

https://ct.googleapis.com/logs/us1/argon2026h1/ct/v1/get-entries?start=0&end=10

Most logs cap the number of entries returned per request (I’ve found commonly found it to be 256), so you’ll need to paginate using start and end:

{
  "entries": [
    {
      "leaf_input": "<base64 MerkleTreeLeaf>",
      "extra_data": "<base64>"
    }
    ...
  ]
}

Decoding the leaf data

The leaf_input field is a base64-encoded binary structure called a MerkleTreeLeaf. Here’s the layout:

Byte 0:      Version          (0 = v1)
Byte 1:      MerkleLeafType   (0 = timestamped_entry)
Bytes 2-9:   Timestamp        (uint64, big-endian, milliseconds since epoch)
Bytes 10-11: LogEntryType     (0 = x509_entry, 1 = precert_entry)

What follows depends on the entry type:

  • x509_entry (type 0): A 3-byte length prefix followed by that many bytes of DER-encoded X.509 certificate.
  • precert_entry (type 1): 32 bytes of issuer_key_hash, then a 3-byte length prefix followed by a DER-encoded TBSCertificate.

The extra_data field contains the certificate chain (minus the leaf).

The full binary format is defined in RFC 6962.

Alternative use cases

OK, so certificates are logged to keep people safe and happy when browsing the internet. What else can we do with them?

Subdomain discovery

Since every publicly-trusted certificate is logged, CT logs are effectively a comprehensive registry of every domain and subdomain that has ever had TLS enabled (excluding wildcart certs and some internal hosts).

The quickest and easiest way to query CT logs is through Sectigo’s crt.sh service, which indexes CT logs and exposes a search interface. For example:

$ curl -s "https://crt.sh/?q=bbc.co.uk&output=json" | jq -r '.[].name_value' | sort -u
24hrhack.test.tools.bbc.co.uk
24hrhack.tools.bbc.co.uk
500words.external.bbc.co.uk
5live.mediapool.tools.bbc.co.uk
...

This example returns every subdomain of bbc.co.uk that has ever appeared in a certificate. Including the ones that were probably never meant to be public, like zenoss.monitoring.tools.bbc.co.uk, ptk-acquisition.test.tools.bbc.co.uk and so on.

Another good search service is MerkleMap.

Tools like subfinder and amass use CT logs as one of their primary passive data sources. If you’re doing bug bounty or red team work, CT logs are one of the first places you should look for during recon.

Real-time subdomain monitoring

Where it gets really interesting is when you set up real-time monitoring. Rather than querying crt.sh after the fact, you can watch CT logs live and get alerted the instant a new certificate is issued for a domain you care about.

This is exactly what my pet project Subpinger does. You give it a list of root domains and it monitors all known and active CT logs in real-time, pinging you whenever a new subdomain surfaces (it also does some other passive and active scanning, but that is besides the point). If you’re working on a bug bounty program and monitoring a target’s infrastructure, this means you can be alerted within minutes of a new service going live. You can often find some low hanging fruit this way.

You can also use tools like CertStream which provides a firehose of all CT log entries in real-time (wss://certstream.calidog.io), though you’ll need to build your own filtering and alerting infrastructure on top of it.

Phishing and impersonation

Attackers who set up phishing sites need TLS certificates to make them convincing. Thanks to CT, that certificate issuance is publicly visible. That means it is often possible to catch dodgy domains before the phishing campaign actually launches.

You can monitor CT logs for issuances that contain your brand name or obvious variations: examp1e-login.com, example-secure-verify.net, exarnple.com

Services like dnstwister allow you to automate this kind of pattern matching.

Time-correlation attacks

A really cool one: research from PT SWARM showed that certificates issued close together in time appear in adjacent positions in CT logs. If you know one domain belonging to a target, you can discover related domains by examining certificates logged near the same index position, even if the domains appear completely unrelated on the surface.

Infrastructure tracking and OSINT

Broadly, CT logs give you a live feed of infrastructure changes across the entire internet. Some other use cases could be:

  • Shadow IT detection: New certificates reveal when teams spin up services outside official channels.
  • Competitor monitoring: Watch when competitors provision new services or expand to new regions.

Covert communication

Researchers have explored using CT logs as a covert communication channel. The idea is that you encode data in certificate fields (SANs, organisation names), submit the certificate to a log, and your recipient reads the data from the public log. The log acts as a publicly accessible, tamper-evident dead drop. Not too sure how practical this one is, but it’s definitely clever.

Wrapping up

Certificate Transparency was built to keep CAs honest, and it does that well. We would be in a sorry state of affairs without it. But the side effect of logging every certificate on the internet is a goldmine for anyone doing security research, OSINT, or red/blue team work.

Useful links: