Skip to content
CertSteady

Certificate Transparency: How CT Logs Reveal Your Subdomains

Every publicly trusted TLS certificate is written to public Certificate Transparency logs. That makes the logs the quickest way to find the certificates and subdomains of a domain, including ones nobody remembers, and it also means every name you put in a public certificate is visible to anyone. This guide explains how the logs work, how to search them, what they reveal and how to keep internal names out.

Last reviewed:

What Certificate Transparency is

Certificate Transparency (CT) is a system of public, append-only logs that record TLS certificates as CAs issue them. It was designed so that a certificate issued by mistake, or by a CA that has been compromised, cannot stay hidden: anyone can read the logs and check what has been issued for their domains.

The original design is specified in RFC 6962. RFC 9162 describes version 2.0 of the protocol; the logs browsers rely on today still largely use the structures from RFC 6962. Both are experimental RFCs, but the system they describe is required in practice: major browsers only trust a publicly trusted certificate if it comes with proof that it was logged.

How CT logs work

Logging at issuance

Before issuing, the CA usually creates a precertificate: the same certificate with a special extension that stops it from being used. It submits the precertificate to several independent logs. Each log returns a signed certificate timestamp (SCT), a signed promise to add the entry within a fixed period called the maximum merge delay. The CA embeds the SCTs in the final certificate, and browsers check them during the TLS handshake. SCTs can also be delivered in a TLS extension or a stapled OCSP response, but embedding is by far the most common.

Merkle trees and proofs

Each log is a Merkle hash tree. The log regularly publishes a signed tree head that commits to every entry so far. Two kinds of proof keep it honest: an inclusion proof shows that a given certificate is in the tree, and a consistency proof shows that a newer tree contains everything an older one did, so entries cannot be removed or rewritten without detection.

Monitors and auditors

Monitors read logs continuously and index their contents, which is what makes searching by domain possible. Auditors check that logs behave correctly, including that promised entries really appear. Browsers and their root programs remove logs that misbehave.

Why every public certificate is logged

A CA does not have to log a certificate, but an unlogged certificate is useless on the public web: browsers that enforce CT reject it. So in practice every publicly trusted TLS certificate in use appears in the logs, along with its precertificate, whichever CA issued it and however it was ordered. That makes CT the most complete public inventory of your certificates, including ones you did not know existed.

Certificates from a private CA, self-signed certificates and certificates used only inside your network are not in public logs, because nothing requires them to be.

Searching the logs

You do not need to read raw logs. Monitors expose search interfaces; the best known public one is crt.sh, which CertSteady also uses. Useful query patterns:

  • example.com returns certificates that name exactly that domain.
  • %.example.com uses % as a wildcard and returns certificates for every name under the domain: www, api, staging.app and so on.
  • The results page offers a JSON output and an option to hide expired certificates, which helps when a domain has years of history.

Some things to expect when reading the results:

  • Most certificates appear twice, once as the precertificate and once as the final certificate. Group by serial number or by names and dates.
  • One certificate can cover many names, and the same name can appear in dozens of renewals. For an inventory, collapse to unique names and keep the newest certificate for each.
  • Large domains can produce very large results, and public search services can be slow or time out under load. Retry later, and use the expired-certificate filter to narrow the result.
  • Entries appear soon after issuance but not instantly; a certificate issued in the last few hours may not show up yet.

What the logs reveal

Each logged certificate exposes, permanently and to anyone:

  • Host names. Every name in the subject alternative name list. This is why CT searches are a standard way to discover subdomains, and why names such as vpn, staging or a project code name become public the moment a certificate is issued for them.
  • Issuer. Which CA and which intermediate issued it, which shows which certificates are likely renewed through ACME and which were ordered by hand.
  • Validity. Start and end dates, so you can see lifetimes and spot certificates that are about to expire or that will be hit by the shorter lifetime limits.
  • History. Every past certificate stays in the logs after it expires. Old names, decommissioned services and earlier CAs remain visible.

What the logs do not show is where a certificate is installed or whether a host is still running. A name in the logs may point nowhere today, and one certificate may be served by many machines. Confirm by connecting to each host.

Wildcards and other blind spots

A wildcard certificate for *.example.com is logged as exactly that: the wildcard, not the hosts that use it. If billing.example.com only ever uses the wildcard, CT will never mention it. Discovery based on CT therefore misses hosts covered only by wildcards, and you need another source, such as your DNS zone or deployment records, to find them.

The same is true for names that never had a public certificate: hosts served over plain HTTP, hosts using a private CA, and hosts behind a provider that uses a shared certificate under its own domain.

Privacy: internal names in public certificates

There is no supported way to keep a name out of the logs and still have a publicly trusted certificate for it. Once issued, the entry cannot be deleted. If the name itself is sensitive, the decision has to be made before issuance. Options:

  • Use private PKI for internal services. Hosts that only staff or internal systems reach can use certificates from your own CA. They are not logged, you control their lifetime, and the shorter public limits do not apply.
  • Use a wildcard where a group of public hosts should not be listed individually, accepting the key-sharing trade-off described in the renewal automation guide.
  • Choose neutral names for public hosts. A name like app2.example.com tells less than one that names a customer, a product launch or the software it runs.
  • Do not rely on obscurity. A host name being hard to guess is not access control. Anything reachable from the internet should be protected as if its name were public, because through CT it often is.

Publicly trusted CAs no longer issue certificates for internal-only names, such as single-label names or private IP addresses, so those cannot leak through CT. The risk is real public names that describe internal things.

How CertSteady uses Certificate Transparency

The CertSteady Certificate Readiness Check starts with a crt.sh query for every name under the domain you enter (%. plus the domain), excluding expired certificates. It then:

  1. cleans the result: lowercases names, strips a leading *. from wildcards, drops duplicates, invalid names and anything outside your domain;
  2. keeps up to 100 host names, shallowest first, so the most prominent hosts are checked when a domain has very many;
  3. connects to each name on port 443 and reads the certificate it actually serves: issuer, expiry, lifetime, TLS version and chain;
  4. estimates which certificates look manually renewed and how many renewals per year they will need under the coming limits.

CT results for a domain are cached for 24 hours, so a certificate issued very recently may appear in the next check rather than this one. Hosts covered only by a wildcard are not discovered, for the reasons above. Only public data is used: the logs and the certificate each server presents to any visitor. See Security for how the scanner behaves.

Sources