Certificate management problems almost always start as a visibility problem. Teams do not forget to renew certificates because they are careless — they miss them because they do not know the certificates exist, or because the information about what exists is scattered across enough different systems that maintaining a complete picture requires constant manual effort that nobody has time for.
The result is that most organisations are managing a partial inventory — the certificates they know about — while a significant portion of their actual certificate footprint sits untracked, unmonitored, and silently accumulating risk.
Why a complete certificate inventory is harder than it sounds
In theory, building a certificate inventory is straightforward: find all your certificates, put them in a list, monitor them. In practice, the sources are fragmented and certificates appear in places nobody thought to check.
Multiple CAs, multiple processes. Large organisations typically have certificates from several Certificate Authorities — a managed CA relationship for production certificates, free Let's Encrypt certificates for automated services, and individual team members who obtained certificates through their cloud provider's certificate manager. There is no single source of truth that covers all of them.
Infrastructure that predates current processes. Legacy systems often have certificates that were set up years ago, before any formal certificate management process existed. Those certificates may still be renewing automatically — or they may be quietly sitting there, long past their renewal date, serving expired certificate errors to nobody in particular because the service itself is barely used.
Third-party and supplier systems. Many organisations have services operated by third parties under their own domain — hosted platforms, managed services, CDN configurations. Those services have certificates too, and unless there is an explicit agreement and monitoring process, those certificates are typically invisible to the organisation's security team.
Certificates added faster than they are documented. Modern infrastructure changes quickly. New services get deployed in CI/CD pipelines. New environments spin up. Developers create test endpoints. Each of these may involve a new certificate, and the documentation process almost never keeps pace with the deployment process.
Three sources that together give you the complete picture
No single source will give you a complete certificate inventory. In practice, a complete picture requires combining three approaches:
1. Certificate Transparency log enumeration. For every public-facing certificate your organisation has ever obtained for its domains, there is a permanent record in CT logs. Querying these logs gives you a complete historical inventory of your external certificate footprint — including things nobody on your team has thought about in years. This is the fastest way to discover shadow IT, forgotten services, and unexpected issuances. It does not cover internal certificates issued by private CAs.
2. Active network scanning. CT logs tell you what certificates have been issued. Active scanning tells you what is actually running and serving those certificates right now. A scanner connects to your hosts on relevant ports, retrieves the presented certificate, and records what it finds — including cases where the certificate presented does not match what CT logs suggest should be there, which is itself an interesting finding. For internal networks, this requires an agent that can reach systems behind your firewall.
3. Direct CA and certificate manager integration. If your organisation uses a managed CA relationship or a cloud certificate manager (AWS Certificate Manager, Azure Key Vault, etc.), those systems have APIs that can provide inventory data directly. This is most useful for production certificates managed through formal processes — it covers the certificates you know about, but it does not help with the ones that went around the process.
The combination of all three gives you something close to a complete picture: CT logs for your external historical footprint, scanning for what is currently active, and CA integration for your managed inventory. Each source catches things the others miss.
What to record for each certificate
Once you have the sources, a useful certificate inventory records more than just the domain and expiry date. The most operationally valuable fields are:
- Domain / Subject Alternative Names — the full list of names the certificate covers, not just the common name.
- Expiry date — the not-after date, with a calculated days-remaining field that updates automatically.
- Issuing CA — which CA issued this certificate, and via what process.
- Environment — production, staging, development, internal. Risk priority depends heavily on environment.
- Owner / responsible team — who is accountable for renewal when the expiry alert fires. Without this, alerts go everywhere and nobody acts.
- TLS grade — the security posture of the endpoint, not just whether the certificate is valid. A valid certificate on a server still running TLS 1.0 is a compliance problem.
- Renewal method — is this certificate renewing automatically via ACME, manually through a CA portal, or managed by a third party? The renewal method determines the risk profile and what monitoring is needed.
- Last seen active — for certificates discovered via CT logs that may or may not still be active, when was the service last confirmed reachable?
The gap between initial inventory and ongoing accuracy
Building an initial inventory is a project. Keeping it accurate is an ongoing operational process — and it is where most manual approaches fall apart.
Infrastructure changes continuously. New services go live. Old services get decommissioned (or do not, but stop being actively managed). Automatic certificate renewals change expiry dates without anyone updating a spreadsheet. Teams are reorganised and certificate ownership becomes ambiguous.
A static inventory — even a thorough one — starts going stale the day it is completed. Within a few months, it will have missed new certificates, still list certificates for decommissioned services as active, and have ownership information that no longer reflects current team structures.
Keeping an inventory current requires that new certificates are discovered automatically and added without manual input, and that the inventory is continuously validated against what is actually live. Both of these require ongoing scanning rather than periodic audits.
What to do when you find the gaps
The first comprehensive inventory exercise almost always surfaces more than teams expect. Common findings:
- Certificates expiring in the next 30 days that nobody had flagged
- Services running outdated TLS configurations (TLS 1.0/1.1, RC4, weak DHE parameters)
- Certificates without clear owners — issued by former employees or teams that no longer exist
- Services that appear to be active in CT logs but are no longer resolving — potential DNS cleanup needed
- Unexpected CAs — certificates issued by CAs your organisation did not authorise via CAA records
- Wildcard certificates covering broader scope than intended
The immediate priority is certificates expiring soon and services with significant TLS configuration problems. Longer-term, ownership gaps and unauthorised issuances are process questions — they indicate where certificate governance needs strengthening.
How CertControl builds and maintains the inventory
CertControl is built around the problem of getting and maintaining a complete, accurate certificate inventory. The platform combines CT log enumeration for external certificate discovery, active scanning for both external and internal networks (the latter via the on-premise agent), and continuous monitoring to keep the inventory current as things change.
Each certificate in the inventory gets a risk score based on expiry proximity, TLS configuration quality, environment, and whether it has a tracked owner. Expiry alerts fire at configurable intervals — 90, 60, 30, and 14 days — routed to the right team rather than broadcast to everyone.
The inventory updates continuously rather than requiring periodic manual audits. New certificates surface within minutes of issuance. Changes to existing certificates — renewed certificates with different expiry dates or SANs — are tracked automatically. The picture stays current without someone having to maintain it by hand.