Post-Quantum Readiness
TLS Certificate Inventory: How to Find Every Certificate in Your Organization
Build a complete TLS certificate inventory across public endpoints, cloud KMS, CDNs, and vendor-managed certs. Step-by-step guide — plus a free, no-signup scan that finds every certificate on your domain in about 30 seconds.
TLS Certificate Inventory: How to Find Every Certificate in Your Organization
Most organizations think they have 50-100 TLS certificates. When they actually inventory, the number is closer to 500-1,500. Forgotten subdomains, expired test certificates, CDN-terminated endpoints, cloud load balancer certificates, and vendor-managed TLS endpoints all hide from the central IT view.
This guide covers every place TLS certificates live and how to find them — external and internal, managed and unmanaged.
Why TLS Certificate Inventory Matters Now
Three forces are converging that make certificate inventory urgent:
- Certificate lifespans are shrinking. The CA/Browser Forum is pushing toward 47-day maximum validity. You cannot manually track certificate renewals at that cadence without an automated inventory.
- PQC migration starts with certificates. Every TLS certificate using RSA or ECC must eventually be reissued with post-quantum algorithms. You need to know which certificates exist before you can prioritize which ones to migrate.
- Compliance requires it. PCI DSS 4.0 (Requirement 4), NIST SP 800-131A, CNSA 2.0, and DORA all require cryptographic visibility and certificate lifecycle management documentation.
What a Complete TLS Certificate Inventory Includes
For every certificate, record:
- Subject (CN and SAN entries — every domain it covers)
- Issuer (public CA, internal CA, self-signed)
- Public key algorithm (RSA, ECDSA, Ed25519) and key size
- Signature algorithm (SHA-256 with RSA, ECDSA with SHA-256)
- Valid from / valid until dates
- TLS version negotiated on the endpoint
- Cipher suite in active use
- Host / endpoint the certificate is installed on
- Owner (which team manages this certificate)
- Renewal process (automated ACME, manual, vendor-managed)
Where Certificates Hide
Layer 1: Public-Facing Endpoints
The most visible layer — and the easiest to inventory. External scanning tools connect to every domain you own and record the TLS certificate presented during the handshake. CipherReady automates this: enter a domain, run a scan, and within minutes you have a certificate-by-certificate inventory with algorithm, key size, issuer, and expiry data.
Layer 2: Internal Services
APIs, microservices, admin panels, database connections, and message brokers often use TLS internally — sometimes with self-signed certificates, sometimes with internal CAs, sometimes with certificates that were issued once and never tracked. Internal inventory requires either agent-based scanning (inspecting file systems, Java keystores, Windows certificate stores) or passive network monitoring at aggregation points.
Layer 3: Cloud Load Balancers and CDNs
AWS ALB, CloudFront, Azure Front Door, Cloudflare, and Fastly all terminate TLS on your behalf. Their certificates are configured through cloud console settings, not through your on-premise certificate management tools. Each cloud provider has its own certificate store (AWS ACM, Azure Key Vault, GCP Certificate Manager) that must be inventoried separately.
Layer 4: SaaS and Vendor-Managed Endpoints
When a vendor provides a service at yourcompany.vendor.com, the TLS certificate on that endpoint is managed by the vendor — but it represents your brand and protects your data. These certificates should be recorded in your inventory as vendor-managed assets with the vendor listed as the owner and a link to their security documentation.
Layer 5: Email Servers and Non-HTTP TLS
SMTP with STARTTLS, IMAP with TLS, database connections with TLS, LDAPS, and other non-HTTP TLS endpoints are frequently overlooked. These often use older configurations and weaker certificates than web-facing services.
How to Build the Inventory
Step 1: External scan (1 day). Run CipherReady on every domain you own. Record every certificate found. This covers Layer 1.
Step 2: Cloud console audit (1-2 days). Log into each cloud provider console and export all certificates from ACM, Key Vault, and Certificate Manager. Cross-reference with the external scan results.
Step 3: CDN and DNS review (1 day). Review DNS CNAME records for CDN and load balancer references. Check each CDN provider's certificate configuration dashboard.
Step 4: Vendor questionnaire (1-2 weeks for responses). Send a certificate inventory request to each SaaS vendor. Ask: which TLS certificate protects our data in transit? What algorithm and key size? Who manages renewal?
Step 5: Internal discovery (2-4 weeks). Deploy agent-based or agentless scanning for internal services. Prioritize systems handling regulated or long-lived data.
Step 6: Consolidate and classify. Merge all data sources into a single inventory. Assign risk tiers. Identify certificates with RSA-2048 or ECC P-256 (quantum-vulnerable) and certificates expiring within 90 days.
FAQ
Q: How many certificates should I expect to find? A: Typically 3-10x more than you expect. Organizations with 50 known certificates often find 200-500. Organizations with 500 known certificates often find 1,500+.
Q: How often should I re-scan? A: Monthly for public-facing endpoints. Quarterly for internal services. On-demand after infrastructure changes.
Q: What if I find certificates I don't recognize? A: Common. Investigate the SAN entries and IP to identify the service. If no one claims ownership and it serves no known purpose, plan to decommission it.
Q: Does CipherReady help with internal certificate discovery? A: CipherReady specializes in external discovery — the public-facing layer. For internal discovery, it complements tools like Keyfactor, DigiCert, or open-source scanners like SSLyze and testssl.sh.
Start Free Readiness Scan →
View Pricing Plans →