Certificate inventory: skip the spreadsheet

Somewhere there is a spreadsheet with every certificate your company has ever issued. Nobody updated it after the person who built it changed teams, and it was never accurate about subdomains in the first place.

That gap used to be tolerable. It is getting worse on its own, because certificate lifetimes are shrinking toward 47 days by 2029, which means the same domain now produces roughly eight times as many renewal events as it did under a one-year certificate. Every one of those events is a new entry that nobody manually adds to a document.

The record already exists, in public, for free

You do not need to build this inventory. Every publicly trusted certificate authority is required to submit certificates it issues to Certificate Transparency (CT) logs, an append-only, publicly auditable record. Chrome has enforced this for all newly issued public certificates since 2018, and every major browser now checks for CT compliance before trusting a certificate.

That means every certificate ever issued for your domain, by any CA, from anywhere, is already sitting in a public record you can query directly. crt.sh is the most commonly used free interface for it: search a domain and get back every logged certificate, in seconds, with no account and no software to install.

A wildcard search catches more than an exact match. Querying %.example.com on crt.sh returns every certificate logged for any subdomain, not just the apex domain, which is exactly the query that turns up the staging environment and the marketing microsite nobody remembered. Each result row links to the full certificate detail: issuer, validity window, and the complete SAN list for that specific entry.

What actually shows up in the log

Each CT log entry carries enough detail to reconstruct the inventory nobody kept:

• Common name and SAN: the domain and subject alternative names the certificate covers, which is often how a forgotten subdomain first turns up.
• Validity window: when the certificate was issued and when it expires, so a spreadsheet with a hand-typed expiry date is no longer the only source of truth.
• Issuer: which CA issued it, useful when a certificate shows up from an authority nobody on the team remembers approving.
• Serial number: a unique identifier for that specific certificate, useful for cross-referencing against what is actually deployed.

Catching a certificate you never asked for

A public log is also a detection tool. Anyone who obtains a valid certificate for your domain, through a mistaken issuance, a compromised CA, or an outright unauthorized request, can impersonate your site convincingly, because the browser padlock looks exactly like it always does. CT logging does not stop that from happening. It makes it visible: a certificate you never requested shows up in the same public record as the ones you did, instead of staying invisible until something goes wrong downstream.

Reviewing that record periodically, rather than only when something already looks broken, is the difference between finding a mis-issued certificate on your own schedule and finding it because a customer reported a warning.

Finding the subdomains nobody remembers

The same data answers a second, unrelated question: what subdomains actually exist. A wildcard certificate's SAN list and every subdomain-specific certificate ever logged together form a running map of what has been deployed, including the staging box from two years ago and the marketing microsite nobody on the current team set up. None of that requires a separate discovery scan. It falls out of the same CT query.

What CT logging does not solve

A public log is not the same thing as monitoring, and it is worth being honest about the gap. CT logs record that a certificate was issued, not that it is currently served anywhere: an entry stays in the log forever even after the certificate expires or is replaced, so the log alone cannot tell you what is live on your servers right now. There is also a delay between issuance and a certificate appearing across every log, typically well under a day but not instant, so it is not a real-time alert feed. And it only covers publicly trusted CAs: an internal certificate authority used for private infrastructure never shows up in a public CT log at all.

That is why reading the log is a review step, not an alerting system. What actually validates the certificate your site is serving right now is a direct check against the live endpoint, which is what SSL monitoring does. The two are complementary: CT logs answer what has ever been issued for this domain, and a direct check answers what is actually running today.

A log beats a spreadsheet because it updates itself

The fix is not remembering to keep a document current. It is watching a record that already updates itself every time a certificate authority issues anything for your domain. WebPixie's Certificates Manager pulls this CT-log inventory automatically for every domain and subdomain you monitor, alongside SAN-based subdomain discovery, so the review happens on a schedule instead of only after someone asks where the spreadsheet went.