The Certificates You Don't Know About
Most teams underestimate their certificate count by a factor of 2 to 3. The certs you don't know about are the ones that take you down - because the failure modes that hit your inventory are the ones you're watching, and the ones that hit everything else are the ones that hit production at the worst possible moment.
Shadow certificates aren't usually anyone's fault. They accumulate through normal operations: a team spins up a new service, a vendor portal issues a cert as part of an integration, an internal CA gets used for kubernetes mTLS, a marketing campaign needs a microsite, someone clicks "request certificate" in the AWS console. None of these are wrong. They just don't end up in your central inventory.
Where shadow certs hide
Four categories cover most cases:
Cloud-issued certs. AWS Certificate Manager, Cloudflare's edge certs, Azure App Service managed certificates, Google's managed SSL. The cloud platform issues, deploys, and renews the cert automatically. Operationally great; inventory-wise invisible unless you explicitly inventory each cloud account.
Vendor portals. Your CRM gives you a cert for your custom subdomain. Your marketing-automation tool, your support platform, your analytics tool - many SaaS vendors issue certs on behalf of customers for their CNAME-pointed subdomains. The cert exists, your domain serves over it, but nobody on your team is tracking its expiry.
Internal CAs. Your kubernetes service mesh issues mTLS certs from an internal CA. Vault issues certs for service-to-service. Your internal PKI signs certs for VPN clients, for build infrastructure, for the dev environment that became a customer-facing thing two years ago and was never re-evaluated. These don't appear in CT logs because they're not from a public CA.
One-off and legacy. The marketing microsite from the 2023 product launch. The acquired company's certs that came along with their domain. The dev cert someone got from Let's Encrypt for testing and forgot was still live. The vendor demo environment that everyone agreed to decommission but didn't.
Why CT log monitoring isn't enough
Certificate Transparency logs are the standard for "find all the publicly-issued certs for your domains." They're necessary - if a CA mis-issues a cert for your domain, you want to know - but not sufficient.
CT covers publicly-trusted CAs that have agreed to log. It doesn't cover internal CAs (your k8s mesh, your Vault, your private PKI), which means it misses every internal-only TLS cert your services use to talk to each other. It misses cloud-managed certs that bypass CT for cost or operational reasons. It misses vendor-portal-issued certs unless the vendor explicitly logs them.
In a typical enterprise environment, CT log monitoring catches maybe half to two-thirds of the certs that actually exist. The remainder require active discovery against your own infrastructure.
Discovery as a continuous practice
A point-in-time audit ("let's figure out what certs we have") works once. Three months later, the inventory is stale again. New services have spun up; old ones have been decommissioned but their certs haven't been revoked; a team adopted a new cloud provider you didn't know they were using.
Continuous discovery means:
- Subdomain enumeration against your own domains, regularly. New subdomains show up; scan them and look for certs.
- CT log subscriptions for your domains, so any newly-issued public cert appears in your inventory automatically.
- Cloud account integration where possible (ACM API, Cloudflare API, etc.) to pull cloud-managed cert inventory.
- Internal CA integration for k8s, Vault, smallstep, or whatever issues your private certs.
- Ownership tagging so each cert is associated with the team that owns the service - because alerts to "everyone" are alerts to no one.
Any one of these can be done with a script. Doing all five continuously, surviving organizational change, is what's hard.
The cert you don't know about is the one that breaks
Every "we had a TLS outage" post-mortem has a moment in it where someone says "we didn't know that service was still running" or "we didn't know that subdomain was on the production load balancer" or "we didn't know that team was using Cloudflare for that domain." The fix isn't usually technical. It's the absence of inventory.
At enterprise scale, the gap between "what we think we have" and "what we actually have" is the largest source of operational TLS risk. Closing it doesn't require new technology - just a discipline of continuous discovery and a single place where every cert lives, regardless of how it was issued.
Find the certs you don't know you have
TLS Radar continuously discovers certificates across your domains, cloud accounts, and internal infrastructure - public-CA-issued, cloud-managed, vendor-portal-issued, and internal-CA-issued, all in one inventory. Ownership tagging routes alerts to the team that owns the service. Built for enterprise teams with API integration, SAML/SSO, and pricing tailored to your certificate volume. Tell us about your stack.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.