--- title: "How to Audit SSL Certificates Across Your Entire Fleet | FourSight" description: "Find every certificate you're responsible for — including the ones nobody remembers issuing — using CT logs, DNS inventories, and network scans." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "How to Audit SSL Certificates Across Your Entire Fleet", "description": "Find every certificate you're responsible for — including the ones nobody remembers issuing — using CT logs, DNS inventories, and network scans.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/auditing-ssl-certificates-across-fleet", "mainEntityOfPage": "https://foursight.cloud/guides/auditing-ssl-certificates-across-fleet", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "wordCount": 1800 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "How to Audit SSL Certificates Across Your Entire Fleet", "item": "https://foursight.cloud/guides/auditing-ssl-certificates-across-fleet" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How do I find all SSL certificates in my organization?", "acceptedAnswer": { "@type": "Answer", "text": "Combine three views: enumerate hostnames from your own DNS zones and infrastructure configs, query Certificate Transparency logs (crt.sh with %.yourdomain.com) for everything ever issued for your domains, and live-scan the resulting list to see what each endpoint actually serves. Each view catches things the other two miss — internal records miss forgotten domains, CT misses deployment state, and scans miss hostnames you didn't know to scan." } }, { "@type": "Question", "name": "What is Certificate Transparency and why is it useful for audits?", "acceptedAnswer": { "@type": "Answer", "text": "CT is the public, append-only logging system that browsers require for trusted certificates — effectively a searchable registry of every certificate issued for your domains. For an audit it surfaces certificates that never appeared in your records: platform-issued certs, forgotten subdomains, and in the worst case unauthorized issuance that deserves a security investigation." } }, { "@type": "Question", "name": "How often should I audit certificates?", "acceptedAnswer": { "@type": "Answer", "text": "A full audit quarterly, with continuous monitoring covering the countdown in between. Quarterly matches the pace at which inventories drift — new subdomains, provider migrations, staff changes — while monitoring handles the part audits can't: alerting when any inventoried certificate approaches expiry or stops validating." } }, { "@type": "Question", "name": "Should staging and internal certificates be in the audit?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, if they're publicly resolvable or user-facing at all. Staging certs expire onto QA teams and demo calls; internal-tool certs train employees to click through browser warnings, which is a security posture problem beyond the individual outage. Inventory them, monitor the ones people rely on, and note deliberate exceptions explicitly." } }, { "@type": "Question", "name": "What certificate details should the inventory record?", "acceptedAnswer": { "@type": "Answer", "text": "Hostname and port, issuer, expiry date, SAN/wildcard coverage, where it's deployed (origin, load balancer, CDN), the renewal mechanism and its location, and a named owner. The renewal-mechanism and owner columns are the ones that convert the inventory from a list into an incident-response tool." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Reliability & Infrastructure # How to Audit SSL Certificates Across Your Entire Fleet Find every certificate you're responsible for — including the ones nobody remembers issuing — using CT logs, DNS inventories, and network scans. 9 min read Guide Published Jul 14, 2026 ## You Have More Certificates Than You Think A certificate audit is the process of enumerating every [TLS certificate](/glossary/certificate "Glossary: 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](/glossary/dns "Glossary: 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. Related Reading - [→ Feature: SSL certificate monitoring](/features/ssl-monitoring) ## 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](/glossary/ssl-tls "Glossary: TLS"). Then walk the infrastructure configs that bind certificates to listeners: load balancer definitions, ingress manifests, [CDN](/glossary/cdn "Glossary: 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](/auth?signup=true) ## 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. [Put your certificate inventory under monitoring →](/features/ssl-monitoring) Related Reading - [→ Certificate chain vs leaf expiry: what actually expires](/guides/certificate-chain-vs-leaf-expiry) - [→ Wildcard vs SAN certificates: monitoring implications](/guides/wildcard-vs-san-certificate-monitoring) - [→ SSL monitoring for agencies & multi-client teams](/guides/ssl-monitoring-for-agencies) ## Frequently Asked Questions ### How do I find all SSL certificates in my organization? ### What is Certificate Transparency and why is it useful for audits? ### How often should I audit certificates? ### Should staging and internal certificates be in the audit? ### What certificate details should the inventory record? #### Related Guides [What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)