How to Audit SSL Certificates Across Your Entire Fleet

You Have More Certificates Than You Think

A certificate audit is the process of enumerating every TLS certificate your organization serves, recording what matters about each one (expiry, issuer, coverage, renewal mechanism, owner), and putting the whole inventory under continuous monitoring. The reason to run one is uncomfortable but reliably true: almost every team is serving certificates it has forgotten about. A typical mid-stage SaaS operates 8-15 distinct certificates once you count the primary domain, www, the API and app subdomains, webhook receivers, the status page, the docs site, the marketing site on a different host, staging environments with public DNS, legacy redirect domains from an old product name, and the mail server. The expiry incident almost never comes from the certificate on your homepage — automation and attention both concentrate there. It comes from the eleventh certificate on that list, the one that wasn't in anyone's inventory because there was no inventory.

Step 1: Enumerate Hostnames from Your Own Sources

Start from the systems that already know your names. Export every DNS zone you control — registrar consoles, Cloudflare, Route 53, whatever holds your records — and extract every A, AAAA, and CNAME that could terminate TLS. Then walk the infrastructure configs that bind certificates to listeners: load balancer definitions, ingress manifests, CDN distributions, reverse-proxy configs, and PaaS custom-domain lists (Vercel, Netlify, Heroku and friends each maintain their own). Finally, ask the humans: marketing owns landing-page domains bought for campaigns, sales tools serve branded subdomains, and the support desk portal has a custom domain someone configured in 2023. The output of this step is a raw hostname list, deliberately over-inclusive — deduplication comes later, but a hostname missed here stays invisible to every subsequent step that starts from your own records.

Step 2: Check Certificate Transparency for What You Missed

Certificate Transparency (CT) is the audit mechanism the web PKI built for itself: since browsers began requiring it, every publicly trusted certificate is recorded in public, append-only logs (the system standardized through RFC 6962). That makes CT logs a searchable history of every certificate ever issued for your domains — including the ones you didn't know about. Query crt.sh with your registered domain (the %.example.com pattern returns all subdomains) and compare the results against your Step 1 list. Expect three kinds of finds: legitimate certificates from platforms that auto-issue on your behalf (CDNs, PaaS providers — fine, but record them), forgotten internal-tool hostnames someone exposed publicly, and — rarely but importantly — issuance you can't explain at all, which warrants a security conversation, not just an inventory entry. Dedicated CT-monitoring services such as SSLMate's Cert Spotter can watch for new issuance on your domains continuously; the audit needs at least the one-time sweep.

Certificate Transparency search:

  https://crt.sh/?q=%25.example.com     (all certs logged for *.example.com)

What to reconcile against your hostname list:
  - Names you expected            -> confirm issuer + renewal owner
  - Auto-issued platform certs    -> record the platform as the renewal owner
  - Names you don't recognize     -> investigate before adding to inventory
  - Recently issued, unexplained  -> treat as a potential security event

Monitoring a Commercial SaaS?

FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.

Start Monitoring Free

Step 3: Scan What's Actually Being Served

Inventory and CT logs tell you what should exist and what was issued; only a live scan tells you what each endpoint is serving right now — which is what your users experience. For every hostname on the consolidated list, perform a real TLS handshake and record the served certificate's subject, issuer, SANs, and expiry. Don't stop at port 443: mail servers (SMTP on 465/587 with STARTTLS, IMAP on 993), databases exposed with TLS, and admin panels on non-standard ports all carry certificates that expire just as hard. A short shell loop covers a first pass; nmap's ssl-cert script sweeps ports at scale. Expect discrepancies between this step and your records — an endpoint serving a different certificate than the one renewed last month is exactly the renewed-but-never-deployed failure mode, caught in an afternoon instead of during an outage.

# Quick expiry sweep across a hostname list
while read -r host; do
  exp=$(echo | openssl s_client -servername "$host" \
        -connect "$host:443" 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  printf "%-40s %s\n" "$host" "${exp:-NO CERT / UNREACHABLE}"
done < hostnames.txt

# Certificate details on any port, not just 443
nmap -p 443,465,587,993,8443 --script ssl-cert example.com

Step 4: Record the Fields That Prevent the Next Incident

The audit's lasting artifact is a small table — a spreadsheet is genuinely fine — whose columns are chosen to answer the 2 AM questions: what is this certificate, who fixes it, and how? For each hostname record the port, issuer, expiry date, SAN coverage (and whether it's wildcard-dependent), where the certificate is deployed (origin, load balancer, CDN — sometimes all three, separately), the renewal mechanism (certbot on which host, cloud-managed, PaaS-automatic, manual), and a named owner. The renewal-mechanism column is the one that earns its keep: in an expiry incident, the difference between 'certbot on web-2, deploy hook reloads nginx' and a blank cell is roughly an hour of archaeology. Review the inventory quarterly — new subdomains, migrations, and offboarded vendors all cause drift — and treat any hostname without an owner as the audit's most urgent finding.

Step 5: Put the Inventory Under Continuous Monitoring

A quarterly audit finds what drifted; continuous monitoring catches what's counting down. Every hostname in the inventory should get an external SSL check that validates expiry, chain completeness, and hostname coverage on an ongoing basis — the audit tells you what to monitor, monitoring makes the audit's protection continuous. On FourSight, each hostname is one SSL monitor with 30/14/7-day alerts (configurable) plus host-mismatch and chain validation on every cycle; a 15-hostname estate fits comfortably in the Growth plan's 100 monitors at $40/mo alongside HTTP checks, and alerts route through escalation policies to whoever the inventory names as owner. The pairing matters in both directions: monitoring without an audit protects only the certificates you remembered, and an audit without monitoring is a snapshot that starts rotting the day you finish it.

Frequently Asked Questions