← Back to Blog

Certificate Discovery: How to Find Every Certificate You Have

By the CertGov team • • 4 min read

Certificate discovery is the process of finding every digital certificate an organization has, wherever it was issued and wherever it is deployed, so each one can be tracked, renewed, and governed. You can't renew a certificate you don't know about, and the certificates that cause outages are rarely the ones on the spreadsheet. Discovery builds an inventory of everything that is actually out there. Here are the four sources to use, and how to keep the inventory current.

Why Inventories Go Stale

Certificates are issued by many people, through many tools, from many CAs. A developer requests one through an ACME client, a contractor buys one with a credit card, an appliance generates its own, and a team stands up a private CA for internal services. None of these show up in a list that someone maintains by hand.

Source 1: Certificate Transparency Logs

Publicly trusted TLS certificates are recorded in public Certificate Transparency (CT) logs, defined in RFC 6962. Since April 2018, Chrome has required newly issued certificates to be logged in order to be trusted, so in practice every certificate that browsers accept appears in the logs.

That makes CT the most complete source for public certificates. Searching the logs for your domains, for example with crt.sh, shows every certificate issued for them by any CA, including ones bought outside your normal process.

Limits: CT shows what was issued, not where it is deployed, and it says nothing about certificates from private or internal CAs. Remember too that the logs are public: a certificate for an internal host name reveals that name to anyone who looks.

Source 2: Network Scanning

Actively connecting to your hosts over TLS shows which certificate each endpoint actually serves, including certificates from private CAs. It's how you find the load balancer still serving last year's certificate, or the internal service with a self-signed one.

Limits: a scanner only sees what it can reach. Scan internal networks from inside, include non-standard ports, and probe by host name as well as IP address, because many servers present different certificates depending on the name requested.

Source 3: CA Inventory Imports

Your commercial CAs and internal CAs already know what they issued. Importing their records catches certificates that were issued but never deployed, or deployed somewhere your scans don't reach, and gives you order and ownership details CT doesn't have.

Source 4: Systems and Stores

Some certificates never face a network you can scan: certificate stores on Windows servers, PEM files on Linux hosts, Kubernetes Secrets, and certificates loaded onto appliances. An agent on those systems, or each platform's API, can report what is installed.

From Inventory to Governance

A list of certificates is only useful if you can act on it. For each certificate, record:

  • An owner and a service, so expiry alerts reach someone who can fix them.
  • Where it is deployed, so renewal reaches every copy.
  • Whether it is covered by policy, so you can tell managed certificates from ones that slipped around the process.

Then look for the findings that matter most:

  • Certificates expiring soon with no renewal in place
  • Certificates from CAs your policy doesn't allow
  • Wildcards, which are worth knowing about wherever they are
  • Weak keys, such as RSA keys shorter than 2048 bits
  • Long-lived internal certificates that outlived their service or owner

Make Discovery Continuous

A one-time inventory starts going stale the day it's finished. Run CT monitoring and network scans on a schedule, alert on new certificates for your domains, and reconcile what you find against what you expected. With lifetimes shrinking toward 47 days, the inventory changes every week.

A Discovery Checklist

  1. Monitor CT logs for every domain you own.
  2. Scan internal and external networks, on all ports that serve TLS, by host name.
  3. Import inventories from each CA you use, public and private.
  4. Collect certificates from servers, Kubernetes, and appliances.
  5. Assign an owner and a service to every certificate.
  6. Flag anything outside policy, then automate renewal for the rest. See automating certificate renewal.

To check a single public site right now, use our free SSL/TLS checker.

How CertGov fits

CertGov discovers certificates through Certificate Transparency log scanning, active TLS probing, and imports from DigiCert, Sectigo, and internal CAs. Every certificate gets a governance status: Tracked, Untracked, or Ungoverned. Policy violations are flagged automatically, and expiry alerts go to the owner of each service.