What Certificate Transparency tells you about your own estate

Certificate Transparency exists so that the public can audit certificate authorities. Every publicly trusted certificate is submitted to append-only logs, and browsers increasingly refuse certificates that are not. The design goal was catching a CA that misissues.

The side effect is more useful to you than the original purpose: CT is a public, searchable, near-complete list of certificates issued for your domains — including the ones you did not know about.

What it finds

Query a CT log for a domain you own and you will typically find three categories.

• What you expected. Good. That is the control group.
• Certificates for subdomains nobody registered centrally. A team spun up staging-v2.example.com, got a certificate in ninety seconds because that is how ACME works, and told nobody. It is real, it is serving, and it will expire.
• Certificates for domains you forgot you owned. An acquisition, a campaign microsite, a product that was renamed. Still resolving, still serving, still yours when it breaks or gets taken over.

The second category is the one that changes how an estate feels. Self-service issuance was the right decision — the alternative was a ticket queue and expired certificates — but it decoupled getting a certificate from anyone knowing you got one.

What it misses, and why that matters

CT only sees publicly trusted issuance. It will never show you:

• Anything from your internal CA — which in most enterprises is the larger half of the estate by count
• Self-signed certificates on appliances and management interfaces
• Certificates on hosts that resolve only inside your network

So CT is one input, not an inventory. Treating it as complete produces a confident, clean dashboard that is wrong — which is worse than an obviously empty one, because nobody investigates a green screen.

Three sources, not one

A real picture needs discovery to come from different directions, because each one is blind in a different place:

• CT logs — public issuance, including what you did not authorise and what you forgot
• Cloud provider APIs — certificates held in ACM, Key Vault, Google Cloud CAS and the load balancers in front of them
• An agent on the host — the PEM file on a box behind two firewalls that no scan and no cloud API will ever mention

The third is the unglamorous one and it is where the surprises live. A certificate that exists only as a file on a machine, referenced by a config nobody has opened in three years, is invisible to every other method — right up until it expires.

The practical version

Start with CT because it costs nothing. crt.sh and the log APIs are free, and one afternoon of querying your own domains will tell you something you did not know. Then add cloud APIs, because they are an authenticated list you already have access to. Then, when you care about being right rather than approximately right, put an agent on the hosts.

You cannot renew what you do not know about, and the failure mode of incomplete discovery is not an error message. It is silence.