Ask any operations team how many TLS certificates they manage. Most will give you a number. Ask them to list every one, and the list is invariably incomplete.
Certificate sprawl is the quiet precondition for every certificate outage. You can't monitor what you don't know exists. Before you invest in automation, monitoring, or process, the first task is taking an honest inventory. This guide covers the four places certificates hide and how to find them.
The Four Places Certificates Live
Certificates don't live in any one system. A thorough audit needs to pull from each of these sources and reconcile the results.
1. Your External DNS
The first pass is straightforward: every TLS-enabled service behind a DNS record you control is a certificate you need to track.
Start with your DNS zones. For each hostname that terminates TLS, there's a certificate. This covers the obvious: www.example.com, api.example.com, mail.example.com. For each, you can verify the currently-served certificate with the SSL Certificate Check on Mr. DNS, which shows expiry, chain, and SANs.
Don't forget subdomains behind wildcards. A *.example.com wildcard certificate is a single cert but may be serving dozens of distinct services, each with its own operational owner.
2. Certificate Transparency Logs
Every publicly-trusted certificate issued since 2015 appears in Certificate Transparency logs. CT is a global append-only record of certificate issuance, originally designed to catch CA misissuance, and now also useful for finding certificates you forgot about.
Search CT for your domain and its subdomains. Public tools like crt.sh return every certificate ever issued for a domain, including:
- Certificates issued to subdomains you don't remember registering
- Test certificates issued during a migration that are still in production
- Certificates issued by development teams without ops knowledge
- Shadow certificates from a vendor who has since left
CT finds the certificates your DNS doesn't reveal: internal-only hostnames with public certificates, staging environments that are still live, and services spun up through SaaS vendors.
3. Internal Infrastructure
Internal certificates are the hardest category because they don't appear in external DNS or CT logs. Possible sources:
- mTLS between microservices (Kubernetes, service meshes)
- Database connections using TLS (PostgreSQL, MySQL, MongoDB, Redis)
- Internal LDAP, Kerberos, and directory services
- VPN concentrators and internal web consoles
- Build systems, artifact repositories, container registries
- Code-signing and document-signing certificates
The discovery methods here are different: scanning internal IP ranges for open TLS ports, pulling certificate inventories from internal CAs (most enterprise CAs support export), and interviewing teams that manage specialized infrastructure. An internal CA like Active Directory Certificate Services or Vault PKI should have a queryable record of every certificate it has issued.
4. Third-Party Services
Certificates managed by vendors are often invisible to your ops team but still represent operational risk. Common examples:
- CDN certificates (Cloudflare, Fastly, Akamai)
- Load balancer or API gateway certificates (AWS ACM, GCP-managed certs)
- SaaS custom domains (custom domains on your helpdesk, marketing site, status page)
- Email gateway certificates (mail relay, anti-spam services)
Most of these are auto-renewed, but "auto-renewed by a vendor" isn't the same as "verified to work." If the vendor fails to renew, the outage is still yours. Any inventory should include third-party-managed certificates with a note about who owns the renewal, even if you don't execute it yourself.
Reconciling Into a Single List
After pulling from all four sources, you'll have overlapping entries. The goal is a single reconciled list where each row is a certificate with at least:
- Hostname or service identifier
- Issuing CA
- Expiry date
- Owner (team or individual)
- Renewal mechanism (automated, manual, vendor-managed)
- Monitoring status (monitored, not monitored)
This list is usually a spreadsheet at first. For a mature setup it belongs in a CMDB, ticketing system, or directly in your monitoring tool where the inventory and the alerting share a source of truth.
The first time you build this list, expect surprises. Certificates from five years ago still in production. Vendors you forgot you had. Subdomains that resolve to internal tools nobody documented. The surprises are the point: each one is a certificate that wouldn't have been monitored otherwise.
Keeping It Current
Inventory is a one-time project that becomes a process. New certificates get issued constantly: a new service goes live, a vendor is added, a team spins up a staging environment. Without ongoing reconciliation, the inventory decays.
CT log monitoring is the first line: set up alerts for new certificates issued to your domains. Any issuance you don't recognize is either an unexpected deployment or a potential security incident. The second is treating your monitoring system as a discovery tool — a system that scans known hostnames for certificate changes will surface new SANs, fingerprint rotations, and renewals automatically, closing the gap between "we issued a new certificate" and "we know about it."
Where Monitoring Fits
A clean inventory is the starting point, not the destination. Once you have the list, each entry needs active monitoring: expiration tracking, chain validation, hostname verification. See SSL Certificate Expiration Monitoring for the specific configuration that catches the failure modes inventory alone can't prevent.
Generator Labs certificate monitoring can ingest a hostname list directly, monitor certificates across public and internal infrastructure, and alert on expiration, chain changes, and fingerprint rotations. For certificates behind firewalls, on-premise agents extend the same coverage inside your network without exposing anything externally.
The first time through, expect to find certificates you didn't know were there. That's the point.