Build a certificate inventory you can actually renew from

A TLS certificate inventory connects certificates to the services that use them. At minimum, it should tell you which hostname needs a certificate, where TLS terminates, who owns the service, when the certificate expires, and how the replacement reaches that endpoint.

Start with a spreadsheet or CSV if that is what you can maintain today. The useful improvement is a record you can execute a renewal from. Moving an incomplete list into a dashboard will not fill in missing owners or device bindings.

Record services and certificate instances separately

The relationship between a certificate and a service is rarely one-to-one. A wildcard certificate may be installed on several appliances. A single application may present different certificates at its CDN, load balancer, and origin.

Use a service record for the hostname, port, business purpose, owner, and client. Use a deployment record for each place that serves the certificate. Connect those records with an identifier you can follow during an incident.

For example, a public portal backed by two reverse proxies has one user-facing service but at least two deployment targets to verify. If the inventory has only one expiry date, it can hide a failed update on the second node.

Include the fields that make renewal possible

These fields form a practical starting checklist:

• Client and service: customer or business unit, service name, hostname, port, and impact of failure.
• Deployment target: device or server, platform version, TLS termination point, and listener or binding.
• Certificate identity: issuer, serial number or SHA-256 fingerprint, names covered, validity dates, and last observation time.
• Ownership: primary operator, backup operator, escalation contact, and change-window requirements.
• Renewal method: ACME client or platform, validation method, DNS owner, and location of the renewal job.
• Key custody: where the private key lives and which controlled identity can use it.
• Verification and recovery: expected live endpoint, application check, prior configuration location, and last successful renewal.

Store references to your credential system, not credentials themselves. An inventory should never contain private keys, DNS tokens, PFX passwords, or device administrator passwords.

Start with a copyable inventory template

This CSV header is a starting point for a small fleet. Each row represents one deployment target. The example is fictional; replace it with your own service details.

client,service,hostname,port,target,binding,owner,dns_owner,issuer,expires_utc,renewal_method,last_verified_utc,runbook
Example Co,Remote access,vpn.example.com,443,edge-01,VPN listener,IT Operations,DNS Team,Example CA,2027-01-15T00:00:00Z,ACME plus appliance install,2026-10-29T12:00:00Z,Internal runbook reference

Add a second target row when the same service runs on a second node. If you track certificate identities separately, include their record IDs rather than duplicating every certificate attribute across rows.

An expiry without a recent observation is only a historical claim. Preserve the timestamp of the probe that supplied it. Your monitoring process should update that observation after every deployment.

Discover candidates, then confirm ownership

Combine the sources you already have: DNS zones, reverse proxy configuration, firewall and VPN configuration, Windows bindings, CA accounts, monitoring systems, and existing renewal tickets. Each reveals a different part of the fleet.

Do not assume every DNS record is a live TLS service. Do not assume a certificate found on disk is installed. Confirm the listening endpoint and the purpose of the service before treating a discovered item as managed.

For customer networks, agree on the scope of any scanning. An internal configuration review and an authorized endpoint probe are often enough for a useful first pass. Public records cannot establish the full set of private services inside a client network.

Prioritize unknowns by business impact

Label missing information explicitly. “Owner unknown” is more useful than an empty cell, because it is work someone can assign.

Start remediation with services whose loss blocks remote access, customer transactions, or your ability to manage the client environment. Then address services that have no verified renewal method. A low expiry count is not reassuring when the inventory misses critical endpoints.

Keep a small queue of inventory exceptions: unowned services, inaccessible DNS, uncertain bindings, stale observations, and certificates whose replacement has never been tested. Review that queue as part of normal service operations.

Make inventory updates part of a service change

Update the record when a hostname, device, certificate, or owner changes. A new application should not enter service without a renewal path. A retired service should leave both the inventory and monitoring, with enough history retained for your operating requirements.

Once the records are useful, connect them to certificate lifecycle management. The next step is to automate the parts that still require a person: validation, installation, and a live check. Certonomy's founding access workflow is aimed at that gap across the launch platforms listed on the site.