A certificate that expires on a production load balancer gets attention because it breaks a login page and pages half the engineering team. But that outage is a symptom of a smaller, quieter failure: nobody had a complete, current list of every TLS certificate the organization had issued. An ssl certificate inventory that only tracks the certificates someone remembers to add is not an inventory, it is a partial log of past incidents. The real value of building one is not avoiding outages. It is discovering domains, subdomains, and services that security teams did not know were running TLS in the first place.
Why certificate inventory is a security exercise, not a renewal calendar
Most teams start tracking certificates because of an expiration scare, so the resulting spreadsheet or calendar reminder is built around one question: when does this expire? That framing misses the more useful question: what does the existence of this certificate tell us about our attack surface? Every issued certificate is a public record that a hostname was, at some point, meant to serve TLS traffic. Certificate Transparency (CT) logs make that record permanent and searchable by anyone, including attackers running reconnaissance against your domain portfolio.
A hostname with a valid certificate but no corresponding entry in your asset inventory is a specific, well-defined signal: either the asset was decommissioned without revoking or letting the certificate expire cleanly, or it was never registered as an asset to begin with. Both cases matter. A decommissioned host with a live certificate can still resolve to an IP under someone else’s control if the DNS record was not cleaned up, which is the setup for a subdomain takeover. A host that was never registered is a gap in your visibility that a vulnerability scanner pointed only at known assets will never reach. Treat certificate inventory as an attack surface discovery input, not a compliance chore, and the rest of the process follows a different set of priorities.
The fields worth recording for every certificate
A usable inventory needs more than a hostname and an expiration date. Pull these fields for every certificate you find, whether through active scanning, CT log queries, or export from a certificate authority’s console:
| Field | Why it matters |
|---|---|
| Full SAN list | A single certificate frequently covers hostnames that are never scanned directly because they were added as a convenience during issuance, not because a service is actively maintained there. |
| Issuing CA and chain | Identifies whether the cert came from an internal PKI, a public CA, or a CDN’s managed certificate service, which determines who can revoke it and how fast. |
| Key algorithm and size | RSA-2048 is the current floor for public-facing certs; anything below that, or any lingering SHA-1 signature, is a finding on its own. |
| Not-before and not-after dates | Not just for renewal, but to spot certificates issued far in advance or with unusually long validity, which often indicates a manual, unmanaged issuance path. |
| Serial number and fingerprint | Lets you deduplicate the same logical certificate seen from multiple vantage points (external scan, CT log, load balancer config) into one inventory record. |
| Resolved IP and hosting provider at time of scan | Ties the certificate to infrastructure ownership, which is what you need when the asset turns out to belong to a forgotten cloud account rather than your primary environment. |
Command-line verification is still the fastest way to confirm any single record. openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName gives you the SAN list, issuer, and validity window in one call, which is useful when reconciling a scanner’s output against what the server is actually presenting. Discrepancies between the certificate a scanner recorded last month and what the host presents today are themselves worth flagging, since they can indicate an unplanned reissuance or a man-in-the-middle condition on a misconfigured proxy.
What wildcard certificates hide
A wildcard certificate such as *.example.com is operationally convenient: one certificate, one renewal, coverage for every subdomain issuance need that comes up. That convenience is exactly the problem from an inventory standpoint. The certificate itself gives you zero information about which subdomains are actually in use. staging-old.example.com, test-2019.example.com, and admin-internal.example.com are all silently covered whether or not anyone remembers they exist, and a wildcard cert does not appear in CT logs with a per-subdomain breakdown that would tip you off.
Set a hard rule: a wildcard certificate does not close an inventory task, it opens a subdomain enumeration task. Combine passive sources (CT log search via crt.sh or a similar aggregator, DNS zone transfers where permitted, historical DNS databases) with active brute-force enumeration against common naming patterns, then check which of the resulting hostnames actually resolve and which serve a live TLS handshake. Any subdomain that resolves but hasn’t been scanned in the current cycle is an unmanaged asset wearing a valid certificate, which is a more convincing phishing or staging-environment target than a self-signed one because the padlock looks correct. Where the risk tolerance allows it, replacing broad wildcards with SAN certificates scoped to a specific, reviewed list of hostnames trades some operational convenience for a meaningfully smaller blind spot.
Internal PKI, third-party CDNs, and free CAs each keep their own inventory, and none of them talk to each other
Organizations rarely have one certificate source. A typical mid-size environment runs an internal PKI for service-to-service mTLS and internal dashboards, a public CA or ACME-based issuer (Let’s Encrypt, ZeroSSL) for internet-facing services, and a CDN or load balancer provider that manages certificates automatically the moment a domain is onboarded, often without anyone filing a ticket. Each of these has its own console, its own export format, and its own idea of what “expiring soon” means.
The failure mode is not that any one of these systems is badly managed. It’s that each is managed in isolation, so a certificate rotated by the CDN provider never reaches the spreadsheet that tracks the internal PKI’s output, and a certificate issued through an engineer’s personal Let’s Encrypt account for a quick proof-of-concept never reaches either. Reconciling these sources means pulling from all three categories on the same cadence and merging on a stable key, typically the combination of primary hostname and serial number, so the same logical certificate discovered through a CDN API export and an external CT log query collapses into one inventory row instead of two. Where the CDN or CA exposes an API (most major providers do), scheduled API pulls are far more reliable than manual console exports, since they don’t depend on someone remembering to check.
Short-lived certificates make a point-in-time inventory obsolete by design
The industry default validity period has been shrinking for years, from multi-year certificates down to 398 days for public CAs, and now toward 90-day and even shorter lifetimes as ACME automation and browser policy push issuers in that direction. A certificate inventory refreshed quarterly, which was defensible when certificates lasted two years, is now stale before the quarter ends. With a 90-day cert, a scan cadence of anything longer than 30 days guarantees you’ll miss at least one full issuance-to-expiration cycle on some hosts, which means you’ll never see the SAN list that was live during that window unless you were watching in real time.
This is the argument for treating certificate discovery as a continuous feed rather than a periodic audit: subscribe to CT log updates for your registered domains (services like crt.sh offer email or API-based monitoring), and re-run external TLS enumeration against your known IP ranges and hostnames on a schedule tighter than your shortest certificate lifetime, not your longest. Platforms that automate this phase, such as SITEY, fold certificate and TLS configuration discovery into the same continuous scanning cycle used for the rest of the external attack surface, so a new SAN entry or a newly issued cert on an existing host shows up as a discovery event rather than something found three months later during a manual review.
Tracing orphaned certificates back to unknown assets
The most useful output of a mature certificate inventory is not the list itself, it’s the set of discrepancies between that list and your asset inventory. Three patterns are worth building explicit checks for:
- Certificate exists, asset record doesn’t. A live, validly signed certificate for a hostname that has no corresponding entry in CMDB or asset inventory. Investigate DNS ownership and hosting provider before assuming it’s safe to ignore.
- Certificate is valid, but the underlying service was decommissioned. The DNS record still resolves, often to a cloud provider’s now-unallocated IP range, which is the precise precondition for subdomain takeover. Check for this specifically whenever a project or environment is torn down, not just when a certificate expires.
- Certificate was issued outside any tracked CA account. Common with free ACME-based CAs, where an individual engineer or a shadow SaaS integration requested a cert independently. These are legitimate uses of TLS but represent issuance you have no control or revocation path over unless you find it.
Each of these traces back to the same root cause: certificate issuance is easy, cheap, and frequently automated at the infrastructure layer, while asset registration is still a manual or semi-manual process in most organizations. Closing that gap doesn’t require stopping automatic issuance, which would be counterproductive. It requires making certificate discovery a standing input into asset discovery, with a defined owner who reconciles the two lists on a cadence shorter than your shortest certificate validity period, and a documented decision path for what happens when a certificate turns up with no known owner: revoke, adopt into inventory, or escalate as a potential compromise indicator.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.