TLS Certificate Inventory and Renewal Runbook

A certificate authority can successfully issue a renewed certificate while the public service continues serving the old one. That gap between issuance and deployment is why a useful TLS certificate inventory needs more than an expiry date. It needs a live endpoint, an accountable owner, a renewal path, and evidence of what clients actually receive.

This proposed TLS certificate inventory and renewal runbook was researched on October 19, 2026. It draws on NIST’s certificate-management guidance and current Let’s Encrypt integration documentation. We have not scanned your systems or tested your certificate automation. Adapt the workflow to the actual certificate authority, infrastructure, client requirements, and operational approvals in your environment.

What a certificate renewal runbook must prove

The runbook should connect four outcomes: the correct certificate is issued, it reaches the intended termination point, the service activates it, and relevant clients can validate the resulting connection. A green issuance job proves only one part of that chain.

NIST SP 1800-16 addresses a formal TLS server certificate management program, including discovery, inventory, ownership, monitoring, and incident recovery. Use that program view rather than treating expiry reminders as the complete control. Your local inventory should explain who acts when automation fails and how the organization verifies recovery.

Do not assume every certificate has the same lifetime or renewal schedule. Public, private, managed, and device certificates can follow different rules. Record the actual validity and issuer guidance. Schedule renewal and escalation from those facts, not an old universal “renew every ninety days” rule.

Discover the endpoints clients actually use

Start with authorized sources: service inventories, DNS and load-balancer configurations, cloud accounts, ingress controllers, reverse proxies, certificate stores, and the teams that operate internal services. Include public websites, APIs, administrative endpoints, internal applications, and other TLS services within your approved scope.

Record the hostname, port, protocol, environment, and network vantage point. One hostname can resolve to multiple serving nodes or take different paths from internal and external networks. The endpoint users reach may terminate TLS at a CDN, load balancer, proxy, or application rather than on the machine where the renewal job runs.

Distinguish the client-facing certificate from certificates on internal connections. Renewing the edge certificate does not automatically update an origin certificate or a separate management listener. Map those boundaries explicitly so an endpoint owner knows which part of the connection they maintain.

Use discovery methods only on systems you are authorized to inspect. Record what the discovery did not cover, including isolated networks or services unavailable from the chosen vantage point. An empty scan result is not evidence that an inaccessible environment has no certificates.

Create an inventory that supports action

For each endpoint, record a stable service identifier, business purpose, technical owner, backup owner, environment, hosting location, and TLS termination point. Add certificate identity details such as issuer, serial or fingerprint, subject alternative names, and validity dates. Keep the collection time and method so reviewers can distinguish an observed certificate from an old configuration record.

Link the renewal mechanism: managed service, ACME client, internal certificate service, or an approved manual process. Record the automation owner, configuration location, deployment target, activation step, and relevant monitoring. Use references to secure key storage; never copy private keys or authentication secrets into the inventory.

Add operational dependencies: DNS control, certificate authority account, challenge method, network access, deployment permissions, and service reload behavior where relevant. A service may have a named owner but still depend on another team for the validation record or deployment credential. Name that dependency before renewal becomes urgent.

Finally, record the latest renewal evidence, live verification result, next action, and unresolved exceptions. An inventory row without an owner or a supported renewal path is a work item, not a completed control.

Inventory area	Example question	Useful evidence
Service identity	Which hostname and listener do clients use?	Endpoint and network vantage point
Ownership	Who can renew, deploy, and approve recovery?	Named primary and backup owners
Renewal path	Which process issues the replacement?	Job and configuration references
Activation	How does the serving component use it?	Deployment and activation result
Verification	What certificate does the endpoint serve now?	Timestamped client-side observation

Design renewal around the issuer and deployment system

Prefer a supported automation path where the platform and certificate authority provide one. Review the current documentation for the exact integration rather than combining commands from unrelated tutorials. The issuer’s renewal behavior and the infrastructure’s deployment behavior are separate dependencies.

The Let’s Encrypt integration guide discusses renewal automation, ACME Renewal Information, retry behavior, and avoiding synchronized renewal load. Where your chosen client supports the relevant current guidance, evaluate that support and document its configuration. Do not claim every ACME client implements every optional mechanism.

Separate authority validation from deployment privileges. DNS validation may require access to sensitive records; deployment may require control over a proxy or secret store. Limit each automation identity to its intended task using supported controls, and record who reviews those permissions.

Use test or staging facilities where the issuer provides them and where they match the intended trial. Confirm their limitations: a successful staging exercise does not establish that a production certificate is trusted by your clients. The final acceptance still needs production issuance and endpoint verification under an approved change.

Make activation and rollback explicit

Document how a newly issued certificate becomes the one the service presents. Depending on the system, this may involve a managed attachment, an updated secret, a configuration deployment, a reload, or another supported activation action. Avoid assuming that writing a file changes every running process.

For multiple nodes or regions, define how the update reaches each relevant termination point. Track partial success. A single successful request may hit an updated node while another route still presents an old certificate. Choose verification vantage points that represent the actual service architecture without claiming exhaustive coverage where it is unavailable.

Define rollback conditions before the change. A rollback needs an eligible certificate, protected key material, supported deployment steps, and an owner who understands the expiry implications. Restoring a previous certificate is not useful if it is already expired, revoked, or inappropriate for the hostname.

Do not disable certificate validation in production clients to make a failed renewal appear successful. If a service cannot present a valid certificate, follow the approved incident and recovery process. Record the impact and repair rather than removing the control that revealed the problem.

Verify the served certificate, not just the job status

After renewal, connect to the actual hostname and port using an appropriate client and the intended server name. Capture the served certificate identity, validity, hostname coverage, and the chain behavior relevant to the client population. Compare the observation with the expected replacement rather than merely looking for a future expiry date.

Check from the relevant network path. An internal administrative test may bypass the CDN or load balancer that public users reach. Conversely, a public edge check may not exercise the internal origin connection. Record which path each result covers.

Then verify the legitimate application action through its normal client workflow. A TLS handshake alone does not prove the application is healthy. Keep application health evidence separate from certificate validation so each team knows what was actually tested.

Retain the issuer job identifier, deployment result, live observation, timestamp, and verifier. Our SSL/TLS explainer covers connection fundamentals; this runbook’s purpose is to prove the operational chain for your specific endpoint.

Use independent monitoring and reachable escalation

Monitor both the renewal mechanism and the endpoint. A renewal job can fail without an immediate outage, while an endpoint can serve the wrong certificate even after the job reports success. These signals answer different questions and should not be collapsed into one status.

Choose alert thresholds from the actual certificate lifetime, renewal behavior, service criticality, and realistic repair time. Avoid presenting a generic number of days as universally sufficient. The owner needs enough time to resolve validation, deployment, or account-access problems before clients are affected.

Test that the alert reaches a person or queue with authority to act. Include a backup route that does not depend entirely on the failing service. An expiry notification sent only to an inaccessible mailbox or an unstaffed former employee account does not provide a useful escalation path.

Record acknowledgment expectations and escalation ownership in the local runbook. These are organizational operating choices, not issuer guarantees. Review whether support coverage and required credentials are available when the planned renewal normally runs.

Failure modes to rehearse before an expiry incident

Validation fails. The challenge path, DNS permission, or network route is no longer available. Identify the dependency owner and use the issuer’s supported diagnostics. Do not repeatedly hammer the production issuance endpoint while the underlying cause remains unchanged.

Issuance succeeds but deployment fails. The replacement exists but the serving component has not received or activated it. Inspect the deployment boundary and verify each intended endpoint afterward.

One node remains stale. Partial rollout creates inconsistent results. Preserve node or route evidence, repair the missed target, and repeat checks through relevant client paths.

The certificate covers the wrong name. A valid chain does not repair a hostname mismatch. Compare the inventory’s actual service names with the certificate and current configuration.

The only owner is unavailable. Renewal depends on a personal account or undocumented knowledge. Use the backup owner and recovery process, then repair ownership rather than accepting another cycle of uncertainty.

Keep certificate incidents distinct from key compromise

An approaching expiry, an incomplete chain, and suspected private-key exposure are not the same incident. Use the appropriate response for the evidence available. A compromised key may require actions beyond ordinary renewal, including issuer-supported revocation and replacement through the approved incident process.

Do not claim that receiving a new certificate proves an old exposed key is harmless. Record whether new key material was required, where it was generated and stored, and which systems stopped using the affected material. Keep private keys out of tickets and analysis tools.

Our digital certificate overview provides broader identity context. For hosted services, also clarify the provider’s responsibilities using the secure hosting guide, then verify the actual contractual and technical arrangement rather than assuming the host handles every certificate.

Frequently asked questions

Is an expiry spreadsheet enough?

It can be an inventory tool, but the record must support ownership, renewal, deployment, monitoring, and verification. A date without a functioning action path does not prevent an outage.

Can we assume a managed certificate needs no review?

No. Confirm the service’s supported behavior, required validation dependencies, attached endpoints, and failure notifications. Managed issuance still needs an accountable service owner and observable results.

How often should the inventory be checked?

Choose a cadence based on lifetime, infrastructure change, service risk, and discovery capability. Also update the record after endpoint changes, renewals, ownership transfers, or incidents. Avoid a fixed interval that ignores your actual renewal window.

Close the loop on one live endpoint

Choose one owned service and connect its inventory row to its renewal job, deployment mechanism, live certificate observation, and escalation route. Resolve every missing owner or dependency before scaling the pattern. The goal is a repeatable proof that clients receive the intended certificate, not merely evidence that a renewal job ran.