The Certificate Inventory Problem (And Why Yours Is Wrong)
Open your garage. Now name everything in it. Not "boxes, bikes, the lawnmower." Specifically: what's in the boxes? How many bikes? Whose tools are in the cabinet you haven't opened since 2022?
Most people, asked this honestly, will admit that their inventory of their own garage is a sketch. They know the big items. They know what they think they have. They're wrong about somewhere between 20% and 80% of the contents.
This is also where most organisations stand on certificates.
The cert inventory in your CMDB, your spreadsheet, your dashboard, your head - it is wrong. Not because anyone lied. Because organisations grow, services spin up, microsites get launched, vendors install software that issues its own certs, acquisitions add their cert mess to yours, and the spreadsheet was never going to keep up.
Here's why the cert inventory problem is universal, where the missing certs hide, and how to actually build one that's true.
Why this matters
Three reasons.
Renewals. If you don't know a cert exists, you can't renew it. The first time you find out is when it expires. By then it's an incident, not a maintenance task.
Compliance. PCI-DSS 4.0, SOC 2, ISO 27001, HIPAA - all of them now ask, in some form, "produce your inventory of certs used to protect customer data." If your answer is "let me check with Bob," you've failed the question before you started.
Incident response. When a vulnerability drops (Heartbleed, ROBOT, the next one we haven't named yet), the first question is: "which of our certs are affected?" If you can't enumerate them, you cannot answer. The clock starts running while you're still discovering what you have.
The inventory isn't the goal. It's the precondition for everything else.
Five places certs hide
The certs you know about are usually the ones on production websites. Here are the five places where the surprises live.
Internal CAs. Service meshes, internal admin tools, VPNs, dev environments - many organisations have more internally-signed certs than externally-signed ones. The internal CA is often a forgotten Vault deployment or an Active Directory Certificate Services install that someone set up in 2019.
Vendor-embedded certs. Enterprise software ships with its own certs. Network appliances, load balancers, monitoring platforms, identity providers - all of them have certs you didn't issue, may not own, and probably can't see without poking at the vendor's UI.
Mobile app certificate pinning. Apps that pin specific certificates as part of their security model. When the pinned cert is rotated and an old app version is still in someone's pocket, the app stops working. The cert is in your inventory as "production web cert." The pinning relationship is not.
Inherited acquisitions. You bought a company. Their certs came with the deal. Their renewal calendar pointed to an email that no longer routes anywhere. Their staging certs are still being renewed by an automation no one can find.
Shadow subdomains. Marketing spun up campaign.example.com for a launch. Engineering spun up internal.dev.example.com for testing. A contractor spun up status.example.com and forgot to tell anyone. Each one has a cert.
The pattern: certs hide everywhere their issuance was done by someone other than the team that thinks they manage certs.
How to actually find them
A real inventory comes from multiple sources, reconciled.
One: Certificate Transparency logs. Every cert issued by a trusted public CA gets logged in CT. CT is a free, public, append-only stream of every cert issued. Search it for your domain - and your domain's subdomains, and the alternate spellings you forgot you owned. You will find certs you didn't know existed.
Two: DNS enumeration and subdomain discovery. Your DNS knows about domains you don't remember. Tools like Amass, Subfinder, or DNS log analysis can surface subdomains your team has created over the years. Each one is a potential cert location.
Three: Cloud provider APIs. AWS Certificate Manager, Azure Key Vault, GCP Certificate Manager - each has an API that will list every cert it manages. Run them on a schedule. Reconcile against your other sources.
Four: Load balancer and CDN configuration. Cloudflare, Fastly, Akamai, and your internal load balancers have lists of certs they're serving. Pull those lists. Compare them to the certs you think you serve.
Five: Network scanning. For internal certs, scan the internal network on common TLS ports. Anything that responds with a TLS handshake is serving a cert. Catalogue what it claims to be and where.
The combination of these five gets you closer to a true inventory than any single source. Each catches what the others miss.
The reconciliation problem
Once you have multiple sources, they disagree. CT logs say you have a cert for a domain you don't recognise. Your cloud account says you have certs for services that don't exist anymore. Your load balancer is serving a cert that's not in any of your other sources.
This is normal. The disagreement is the inventory's most valuable output. Each discrepancy is a question worth answering.
- A cert in CT that you don't recognise: did someone in your org issue it? Did a vendor? Is it actually for your domain, or is it an attacker's cert that you should report? A cloud-managed cert for a defunct service: should the service be deleted, or is it still active and quietly serving something? A load balancer cert that's not anywhere else: who configured this load balancer, when, and is it still in scope?
A quarterly walk-through of the discrepancies, with a real human, is the single most useful operational hygiene practice for cert management. It costs an afternoon. It surfaces six months of accumulated drift.
Keeping it true
The inventory is not a project. It is a process.
- The discovery runs on a schedule (daily, weekly - depending on cert churn). New certs that appear in CT logs trigger a "is this ours?" check. Decommissioned services get their certs removed from the inventory. Ownership is tracked at the cert level, not the service level - because services get renamed, owned by different teams, or deprecated, and the cert often outlives all of that.
A complete inventory that updates itself is one of the few infrastructure investments that genuinely pays off forever. Renewals get easier. Audits get easier. Incident response gets faster.
One small ask
If you cannot list every cert your organisation has, in under five minutes, from a source that updates itself, you have a garage. TLS Radar will give you an inventory of every cert across your domains, continuously discovered from CT logs and your own assets, with ownership tracking and external monitoring on top. Free tier covers three domains, which is enough to see what's already there that you didn't know about.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.