What Certificate Transparency Reveals About You

Quick answer: Certificate Transparency, or CT, is a system that records every TLS certificate ever issued into public, append-only logs that anyone can search. It exists for a good reason: to catch certificates issued fraudulently or by mistake. The side effect is that the hostname on every certificate becomes permanent public record, so every subdomain your organisation ever requested a certificate for, staging servers, VPN gateways, internal tools, unreleased products, is readable by a stranger at a website called crt.sh, without touching your servers at all. I ran this against all 42 of my own domains. Most disclosed almost nothing, for one specific architectural reason, and two disclosed their whole service map, for another.

There is a public ledger, updated in real time, that lists a certificate for nearly every HTTPS site that exists, and it has been running since 2013. You are in it. Every domain you own is in it. Most people who run websites have never looked at it, and a good number would be unsettled by what their own entry contains.

It is not a leak in the breach sense. Nobody stole anything. The system was built on purpose, by Google, for a genuinely important reason, and its openness is the entire point. But openness cuts both ways, and the same property that lets a security researcher catch a forged certificate lets anyone else read the names of servers you thought were private. This is the cleanest example in the whole receive-first idea: no packet is sent to you, and your own certificate authority did the disclosing.

Why the log exists

The reason is worth understanding, because it explains why CT is not going away and should not.

Before CT, a certificate authority could issue a certificate for your domain and you would have no way to know. If a CA was compromised, or careless, or coerced, it could sign a certificate for yourbank.com and hand it to an attacker, who could then impersonate your bank with a padlock in the address bar and no warning. This was not hypothetical. In 2011 a CA called DigiNotar was breached and issued fraudulent certificates for Google and others, used to intercept traffic in Iran. Google later found Symantec had misissued certificates over a period of years.

CT fixes the blind spot by requiring that every certificate be published to public logs before browsers will trust it. Now a domain owner can watch the logs and see the instant anyone, anywhere, gets a certificate for their name. A forged certificate cannot hide, because issuing it announces it. It is a genuinely elegant piece of security design, and modern browsers enforce it: a certificate not present in CT logs is rejected.

The catch is in the word "public." To let you catch a bad certificate for your domain, the log has to be readable by everyone, for every domain. Including yours.

The side effect: your hostnames are public, forever

A certificate binds a name to a key. So the log entry contains the name. Every name.

When a company requests a certificate for `staging-payments.example.com`, that hostname goes into a public log the moment the certificate is issued, and it stays there permanently because the logs are append-only. You cannot delete an entry. A subdomain you exposed once, five years ago, for a project that no longer exists, is still legible today.

This turns certificate issuance into an unintentional public announcement. Standing up a new internal tool and giving it HTTPS, which every sensible person does, publishes the tool's name. Preparing an unreleased product on a subdomain and securing it, which again is correct, can telegraph the product before launch. Security tooling scrapes these logs continuously for exactly this reason, and so do attackers, because reading crt.sh is faster, quieter, and more complete than scanning.

None of it requires touching the target. That is the whole point of this series: the information is emitted by the target's own CA and merely read.

I audited my own domains

Talking about this in the abstract is cheap. So I pointed the technique at myself and read the CT logs for every domain I own, 42 of them, using nothing but the public crt.sh interface. No scanning, no login, one public log. crt.sh returned a 502 on six of the queries, which is just its free infrastructure straining under rapid requests, so the numbers below cover the 36 that answered.

Here is what came back:

CT SELF-AUDIT  (42 domains, read from public logs only)

  domains audited                  : 42
  returned data (6 were crt.sh 502s): 36
  unique subdomains disclosed,
    across all 36 combined          : 21
  domains using a wildcard cert     : 36 of 36
  domains leaking an infra hostname : 1

  the two biggest leakers were both on cPanel hosting:
    8 subs   www, mail, webmail, webdisk, cpanel,
             autodiscover, cpcalendars, cpcontacts
    6 subs   www, mail-style host + duplicate-cert cruft
             (www.www, www.sitemap: misconfigured reissues)

  every other domain disclosed almost nothing:
    www           (benign, present nearly everywhere)
    sitemaps      (ONE straggler cert on a wildcard site,
                   now in the public log permanently)

Twenty-one subdomains total, across thirty-six domains. For a portfolio that size that is very little, and both the reason it is so little and the exceptions are the interesting part.

Why most of them disclosed almost nothing

All 36 domains that answered use a wildcard certificate: a single certificate issued for `*.example.com` rather than a separate one per hostname. Every one of them sits behind Cloudflare, which provisions a wildcard as part of its universal SSL.

A wildcard changes what the log sees. Instead of one entry per subdomain, spelling each name out, there is one entry that says `*.example.com` and nothing more. The asterisk covers `app`, `staging`, `vpn`, `internal`, anything, without naming any of them. The subdomains exist and are served, but their names were never written to a public log, because no certificate was ever issued that contained them individually. That is why most of my domains disclosed only `www`, which is universal and tells no one anything.

So the architecture that most of my sites happen to use, a wildcard behind a reverse proxy, is an accidental privacy feature. It was not chosen for that. It is a side effect of how Cloudflare issues certificates. But the effect is real: a domain served this way discloses its apex name and a wildcard, and keeps its internal structure off the public record.

Why two of them disclosed their whole service map

The two exceptions were domains running on ordinary cPanel shared hosting rather than behind a proxy. The worst of them disclosed eight hostnames by name: `cpanel`, `webmail`, `webdisk`, `mail`, `autodiscover`, `cpcalendars`, `cpcontacts`, and `www`.

The cause is a feature called AutoSSL. cPanel automatically issues a free certificate for each service it runs, and it does so per hostname, not as a wildcard. Every one of those per-hostname certificates is a separate public log entry that spells the hostname out. The hosting panel, trying to be helpful by securing everything, published the name of everything it secured. Read those eight names together and you can identify the hosting stack, the mail setup, and the admin surface at a glance, all without sending a packet at the server.

Those particular names are generic and low-stakes; they are the same on millions of cPanel sites and reveal mainly that the domain is on cPanel. But the mechanism is the lesson. On a server that issues per-host certificates, every hostname you add, including the ones you would not want advertised, becomes a public announcement. Swap that benign set for `vpn`, `jenkins`, `backup`, or `admin-internal`, and the same automatic behaviour hands an outsider a map of your infrastructure.

The straggler, and why the log never forgets

One finding deserves its own line, because it is the trap in miniature. Among the wildcard-protected domains, which should have disclosed only `www`, exactly one also disclosed a `sitemaps` host. Its subdomains are otherwise hidden behind the wildcard. This one is not, because at some point a certificate was issued for that specific hostname, probably years ago and probably forgotten.

That single named certificate is in the public log forever. The wildcard the domain uses today does nothing to retract it, because CT is append-only and retracts nothing. It is a clean demonstration that CT privacy is not a state you reach and keep. One certbot run on one subdomain, once, and that name is permanent public record no matter what you do afterward.

The part where I tell you wildcards are not a free win

It would be easy to end at "use wildcards, stay private," and it would be wrong. Wildcards trade one risk for another.

A wildcard certificate has one private key that authenticates every subdomain. If that key is stolen, the attacker can impersonate all of them. Per-host certificates contain the blast radius: a compromised key for `mail.example.com` does nothing for `vpn.example.com`. The security teams that deliberately avoid wildcards do so for exactly this reason, and they accept the CT disclosure as the cost.

There is also a permanence trap. A wildcard hides subdomains only for as long as nobody ever issues a named certificate for one. The moment someone runs certbot on `staging.example.com` because they wanted a quick cert for a test box, that name is in the log forever, wildcard or not. CT privacy is not a property you can set once. It is a discipline every certificate request has to respect, permanently, because the log never forgets.

And none of this hides a subdomain from other channels. Passive DNS, brute-force resolution of common names, and the contents of the site itself can all surface a hostname that CT does not. A wildcard closes one window. It does not close the house.

What this looks like from the other side

Put yourself in the position of someone mapping a target. The old way was to scan: fire DNS queries and connection attempts at guessed hostnames, which is slow, incomplete, and leaves your address in logs. The CT way is to open crt.sh, type the domain, and read a complete, authoritative list of every hostname the target ever certified, assembled by the target's own certificate authorities, with no packet sent and no trace left.

For any domain that issues per-host certificates, that list is the internal map. For a domain behind a wildcard, the list is disappointingly short, which is the entire point of this article. The defender's architecture decides which of those two the attacker gets, and most defenders have never looked at their own entry to find out.

How to read your own, in one minute

This is re-runnable, and you should run it, because the log is public and reading your own costs nothing.

The fast way. Go to `crt.sh`, and in the query box enter your domain with a wildcard prefix:

%.example.com          <- paste this into the crt.sh search box

The `%` is a SQL wildcard, because crt.sh is a searchable database of the logs. You get every certificate ever issued for a subdomain of your domain. Read the Common Name and Matching Identities columns and you are looking at exactly what a stranger sees.

The scriptable way. crt.sh returns JSON, so you can pull and sort your whole footprint from a terminal:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | tr ',' '\n' | grep name_value | sort -u

Read the list with one question in mind: is there anything here I did not mean to make public? A hostname that names a vendor, an internal tool, an unreleased project, or a piece of infrastructure is a hostname worth rethinking.

How to reduce your footprint

You cannot remove anything from CT; the logs are append-only and permanent. What you can do is stop adding to it and start watching it.

• Prefer a wildcard behind a proxy for sites that do not need per-host certificates. It keeps subdomain names out of the log, with the key-blast-radius tradeoff understood and accepted.
• Name internal hosts on the assumption that the name will be public. If a certificate might ever be issued for it, treat the hostname as an announcement. `vpn-frankfurt-prod` tells a stranger a great deal; a boring name tells them less.
• Monitor CT for your own domains. Free services will email you the instant a certificate is issued for your domain. This is the original purpose of CT, catching a certificate you did not authorise, and it is worth having on for every domain you own.
• Set a CAA record. A DNS CAA record tells the world which certificate authorities are allowed to issue for your domain, so a rogue issuance is both visible in CT and refused by compliant CAs.

None of that is a product you buy. It is knowing that certificate issuance is publication, and behaving accordingly.

The wider point

Nothing here was an attack. I read a public log about my own domains and learned which of them had been quietly announcing their structure to anyone who looked. The information was published, by automated systems doing their job correctly, and all it took to collect was knowing where to read.

That is the thread running through this whole series, gathered in the field guide to receiving before you send. A photo publishes the coordinates where it was taken. A document publishes the name of everyone who edited it. And a certificate publishes the name of the server it protects. In every case the defence is the same: find out what you are broadcasting by default, and change the defaults that are saying too much.

Frequently Asked Questions

What is Certificate Transparency?

It is a system, introduced by Google in 2013 and now enforced by major browsers, that requires every TLS certificate to be recorded in public, append-only logs before it is trusted. The goal is to make fraudulent or mistaken certificate issuance impossible to hide, since issuing a certificate necessarily publishes it. A side effect is that the hostname on every certificate becomes public, searchable record.

Can anyone see my subdomains through Certificate Transparency?

If you use per-host certificates, yes. Any subdomain that has ever had its own certificate is readable by anyone at a site like crt.sh, with no access to your servers. If your domain uses a wildcard certificate, individual subdomain names are not written to the log, only the `*.yourdomain` entry, so they do not leak through CT, though they can still surface through other means such as passive DNS.

How do I check what my domain has exposed?

Go to crt.sh and search for `%.yourdomain.com`, including the percent sign, which lists every certificate ever issued for a subdomain of your domain. For a scriptable version, request the same query with `&output=json` appended and parse the `name_value` fields. Read the results and look for any hostname you did not intend to make public.

Is Certificate Transparency a security risk?

Not in itself; it is a net security gain, because it lets domain owners detect unauthorised certificates and forces certificate authorities to be accountable. The exposure it creates is informational: it reveals hostnames. The right response is not to oppose CT but to treat certificate issuance as publication, use wildcards where appropriate, name internal hosts carefully, and monitor the logs for your own domains.