Every TLS certificate an organization issues – whether through a managed process or by a developer clicking through Let’s Encrypt on a Friday afternoon – creates a public record that outlives most people’s memory of why it was requested. A certificate inventory mapped to active subdomains closes that gap: it ties every issued certificate back to the subdomain it protects, flags the ones pointing at nothing, and gives security teams a way to answer “what’s actually running on port 443 across our entire domain” without guessing.
Most organizations run this backwards. They track certificates in whatever tool issued them – ACM, Certbot, an internal PKI, a vendor’s dashboard – and track subdomains in a completely separate spreadsheet, if at all. The two lists rarely get reconciled, and that’s exactly where the risk sits.
Why certificate and subdomain records drift apart
A certificate gets issued when a service goes live. Six months later the service gets decommissioned, the DNS record either stays pointed at a now-unclaimed cloud resource or gets quietly deleted, but the certificate itself doesn’t disappear from the certificate authority’s records. Certificate Transparency logs, mandated for all publicly trusted certs since Chrome enforced CT compliance in 2018, keep a permanent public record of every certificate ever issued for a domain – including ones for subdomains nobody remembers creating.
This is why attackers run CT log searches (crt.sh is the common starting point) as step one of reconnaissance. A certificate for `staging-payments.example.com` issued in March 2023 tells an attacker that subdomain existed, likely still resolves somewhere, and probably wasn’t decommissioned with the same care as production. They don’t need to guess subdomain names anymore; the CA industry hands them a list.
Building the mapping: certificates to live subdomains
A proper inventory answers three questions for every certificate found in CT logs or internal PKI records: does the subdomain it covers still resolve, does the resolved endpoint still belong to the organization, and is the certificate itself still valid and correctly configured.
The practical steps look like this:
– Pull every certificate issued for the domain and its subdomains from CT log search, going back at least 24 months
– Cross-reference each certificate’s Common Name and Subject Alternative Names against current DNS records for those hostnames
– For subdomains that still resolve, check whether the destination (an S3 bucket, a Heroku app, a CNAME target) is still owned by the organization
– Flag certificates covering subdomains that no longer resolve at all – these are candidates for CT log-based social engineering, since the name still looks legitimate in a phishing URL
– Record expiration dates and issuing CA for everything that remains active
Wildcard certificates complicate step two significantly. A single `*.example.com` cert can cover 40 subdomains that were never individually documented anywhere, which is part of why wildcard DNS records and wildcard certs tend to be issued around the same time – someone decided documenting individual names wasn’t worth the effort.
The myth that expiration monitoring is enough
A lot of teams believe that once they have a certificate expiration alert configured – Nagios, a cron job hitting `openssl s_client`, whatever – they’ve covered certificate risk. That’s not the same thing as a subdomain-mapped inventory, and treating it that way misses the bigger exposure.
Expiration monitoring only watches certificates you already know about and have configured a check for. It says nothing about the certificate issued for `old-partner-portal.example.com` in 2021 that nobody added to the monitoring list because the person who requested it left the company in 2022. That certificate might still be valid, still resolving to an S3 bucket the organization stopped paying for, and sitting there as a ready-made subdomain takeover target. Expiration monitoring would never flag it, because from its perspective there’s nothing to expire yet.
Common mistakes teams make with certificate data
The first mistake is treating the CA’s issuance dashboard as the source of truth. It only shows certificates issued through that specific CA or ACM account – anything a contractor requested through Let’s Encrypt directly, or a certificate issued for a subdomain during a short-lived marketing campaign, won’t show up there. CT log search is CA-agnostic and catches all of it.
The second mistake is checking certificate validity without checking DNS resolution in the same pass. A security team might confirm a cert is unexpired and trust that the subdomain is fine, without noticing the CNAME behind it now points to a deprovisioned Azure resource. The certificate being valid says nothing about what’s actually serving traffic underneath it.
The third mistake, and the most common one: running this exercise once during an audit and calling it done. A seasoned security lead treats certificate-to-subdomain mapping as a recurring pass, not a one-time project, because new subdomains and their certificates get created continuously – marketing spins one up for a campaign, a developer stands up a demo environment, an acquired company’s subdomains get folded in. Dangling CNAME records accumulate the same way stale certificates do, quietly, between review cycles.
Making the inventory operational
An inventory that lives in a spreadsheet updated quarterly is better than nothing, but it’s already stale by the time anyone reads it. Continuous subdomain discovery combined with automated CT log monitoring closes that gap – new certificate issuance for the domain triggers a check against current DNS records automatically, rather than waiting for the next scheduled review.
This matters more at organizations with distributed ownership of DNS – marketing teams provisioning their own landing pages, engineering teams standing up preview environments per pull request, individual business units running their own subdomains under a shared parent domain. None of those teams think about certificate lifecycle when they spin something up, and none of them think about it again when they tear it down.
FAQ
How often should a certificate-to-subdomain inventory be refreshed?
CT log data updates continuously, so the inventory should ideally refresh weekly at minimum, with automated alerting on new certificate issuance for any subdomain of the monitored domain. Quarterly manual reviews miss certificates issued and abandoned within a shorter window.
Does this replace a standard asset inventory?
No. It’s a complement that specifically closes the DNS-and-certificate blind spot. A full digital asset inventory should still track infrastructure ownership, application details, and business context that certificate data alone can’t provide.
What’s the fastest way to check for orphaned certificates right now?
Query crt.sh for the parent domain, export every distinct hostname from the results, then resolve each one against current DNS. Any hostname that no longer resolves, or resolves to infrastructure the organization no longer controls, needs immediate attention regardless of whether its certificate has expired.
Certificate Transparency logs were built for accountability, not convenience, but they end up functioning as an unintentional map of everything an organization has ever exposed publicly. Treating that map as part of the DNS security process – rather than something only certificate authorities care about – catches exposure that expiration alerts and manual subdomain lists both miss.