Abstract
There is a public record of every TLS certificate ever issued for your domain, and anyone can search it. Most people who run infrastructure have never heard of these certificate transparency logs.
So I read our own log, and here’s what anyone could learn about CertKit from them.
What the certificate transparency logs say about us
A search for certkit.io returns 93 certificates.
Every renewal issues a brand new certificate, and the log keeps all of them forever. The thing you actually manage is the certificate lineage, the series of certificates with the same name. There are 15 lineages, ten of them active. One is a wildcard for *.certkit.io that renews every six days.
Every certificate we have is from Let’s Encrypt, which tells you we automate. Fine, I’m okay that you know that.
The rest I might not advertise. Three of our certificates cover dev-app.certkit.io, dev-storage.certkit.io, and dev-storage-ui.certkit.io. Our development environment is named and dated. Nobody scanned us or touched our network to learn that. The information was published, by us, as a side effect of getting certificates.
Four more names give away most of our vendor stack. crm.certkit.io resolves to HubSpot. errors.certkit.io resolves to TrackJS. rm.certkit.io resolves to Request Metrics. ph.certkit.io is our PostHog proxy. A competitor who wanted to know what we buy could skip the research and read the log.
The five dead lineages tell a story too. Through May we were issuing individual certificates for app.certkit.io, storage.certkit.io, and storage-ui.certkit.io. By the middle of August those were gone, replaced by a six-day wildcard covering *.certkit.io. Anyone watching the log watched us change how we run certificates, and can date the change to within a few days of when it happened.
The system is working exactly as designed.
Why certificate logs are public
In 2011 an attacker got inside a Dutch certificate authority called DigiNotar and issued a working wildcard certificate for *.google.com, along with more than 500 others. It was used to read the traffic of roughly 300,000 people, better than 99 percent of them in Iran. DigiNotar spotted the intrusion in July and said nothing about it until the certificate turned up in public at the end of August. Trust was pulled within days. The company was declared bankrupt three weeks later.
A CA could issue a certificate for your domain and nobody, including you, had any way to find out. You had to trust their auditor. There were no receipts.
Google forced the industry to build certificate transparency logs. Every certificate from a publicly trusted CA gets written to append-only public logs, and browsers demand signed receipts from those logs before they will accept it. A certificate from a public CA that never got logged doesn’t work in the browser.
It worked. Certificate transparency is how Symantec (the largest CA in the world at the time) got caught issuing certificates for domains it had no business touching. Google’s investigation put at least 30,000 certificates in question. The official security audits of the CA didn’t find this, the CT logs did. Chrome distrusted the certificates in stages, and Symantec sold the business to DigiCert before the distrust finished landing.
Your hostnames being readable is the same property viewed from the other side. A log that lets the world catch a CA misbehaving is a log that lets the world read your subdomains.
You made that trade when you got the certificate.
Go read yours
You can search your own domain right now. It only takes a minute and you don’t need an account. Four things are worth looking for:
-
Start with the issuing CA. If your organization buys from one CA and the log shows certificates from another, somebody outside your team is issuing on your behalf. Our own Request Metrics domain is entirely Let’s Encrypt except for one certificate on
keyword-vitals.requestmetrics.comfrom Google Trust Services. That host runs on DigitalOcean, which issues its own certificates. Nobody on my team decided that. The platform did. -
Then look at the hostnames themselves. You are looking for names you do not recognize, projects that were shut down years ago, and dev or staging environments that somebody assumed were private because they are not linked from anywhere.
-
Check the lifetimes. A certificate with a year or more between issue and expiry is one that someone renews on a calendar, which is fine until they retire or change jobs.
-
Count your wildcards. Teams that have been around a while tend to have more than they meant to, issued by different people for different reasons, each one covering more than anybody remembers.
The log records what was issued, not what was installed or where. A certificate in the log might be sitting on a server, or on four servers, or on nothing at all. It tells you what exists, which is where to start with certificate discovery.
What the log cannot tell you
Everything above is free because those certificates are public. Internal certificates don’t work that way.
In May I wrote that you probably do not need private PKI for internal infrastructure, and that a wildcard can work for internal hosts, especially for small teams. Part of the argument was that individual certificates for vcenter.int.example.com and firewall.int.example.com publish a target list, and a wildcard for *.int.example.com does not. I stand behind that.
Having a private CA goes further and publishes nothing at all, but now you have a new job to run your own PKI infrastructure.
If you need private PKI but dread the idea of running PKI yourself, check out the CertKit managed PKI service, and let us issue and deploy your internal certificates.
The public half of your infrastructure has a free, complete, externally maintained inventory that you can read on a Monday morning without asking anyone’s permission. The internal half has no log, answers no prober from the outside, and appears in no public record anywhere. What you know about it is whatever the person who set it up wrote down.
CertKit automates certificate lifecycle management, so the list of what you are running is not something you maintain by hand.