Certificate lifecycle management is the operational discipline of knowing which certificates exist, who owns them, when they expire, how they are renewed, and how they are revoked when trust is no longer appropriate. This runbook gives IT teams a reusable certificate inventory template, scenario-based checklists, renewal steps, and an incident checklist for websites, APIs, devices, and internal services.
Overview
A certificate is rarely just a file on a server. It may be referenced by a load balancer, application gateway, API client, mobile device, container, deployment pipeline, or business partner. A missed expiration can interrupt service, while an unmanaged private key can create a security and compliance risk even when the certificate itself remains valid.
Effective certificate lifecycle management has four connected activities:
- Inventory: discover certificates and record enough metadata to identify their purpose, owner, location, and dependencies.
- Renewal: replace certificates and update dependent systems before expiration, using a tested and documented method.
- Validation: confirm the certificate chain, hostname coverage, algorithm, deployment, and service behavior after a change.
- Revocation and retirement: remove certificates and keys that are compromised, no longer needed, or associated with decommissioned services.
Use a central inventory as the operational record, but do not treat it as proof that every certificate has been found. Compare inventory data with certificate discovery, deployment records, cloud platforms, DNS, configuration repositories, and Certificate Transparency monitoring where applicable. The Certificate Transparency Logs guide explains one useful way to identify publicly visible certificates that may not appear in internal records.
Certificate inventory template
Store one record per certificate and keep the fields consistent. The following columns are a practical minimum:
| Field | What to record |
|---|---|
| Certificate ID | A stable internal identifier, not only a filename. |
| Owner | The accountable person or team, including an escalation contact. |
| Service and environment | Website, API, device, internal service, production, staging, or development. |
| Hostname or subject | Primary hostname and relevant subject alternative names. |
| Deployment location | Server, load balancer, ingress, appliance, cloud service, keystore, or device group. |
| Issuer | The certificate authority or issuing system. |
| Serial number and fingerprint | Values used to distinguish the certificate during validation and incident response. |
| Algorithm and key type | Signature algorithm, public-key algorithm, and key-size or curve details as applicable. |
| Issued and expiration dates | Dates used for renewal planning and monitoring. |
| Renewal method | Automated, manual, API-based, device-specific, or supplied by a third party. |
| Dependencies | Services, clients, trust stores, integrations, or change records affected by replacement. |
| Revocation status | Active, revoked, expired, retired, or pending validation, with the check date. |
Checklist by scenario
Public websites and customer-facing APIs
- Identify every hostname, including alternate names and domains served through a shared edge platform.
- Record where TLS termination occurs. The certificate may be installed on a CDN, reverse proxy, gateway, or load balancer rather than the application server.
- Check the complete certificate chain, hostname match, expiration, and private-key association.
- Confirm that the renewal method can update the actual termination point and reload the service safely.
- Test the renewed endpoint from an external network and from representative client environments.
For a deeper validation pass, use the SSL certificate checker guide to review chain, expiration, and TLS configuration issues.
Internal services, APIs, and mutual TLS
- Map both sides of the connection: server certificate, client certificate, trust store, and any intermediate certificates.
- Record which applications, service accounts, containers, and scheduled jobs depend on the certificate.
- Check whether clients validate the issuing chain, subject name, key usage, or extended key usage.
- Plan overlapping deployment where the platform permits it, so dependent clients can receive the replacement before the old certificate is removed.
- Test authentication in a non-production environment and verify logs for handshake or trust errors after deployment.
Devices, appliances, and offline systems
- Record firmware, operating system, device group, physical or remote access method, and maintenance window.
- Confirm that the device supports the replacement certificate, key algorithm, chain, and validity requirements.
- Document how private keys are generated, imported, backed up, and protected.
- Keep a rollback plan that does not require distributing an old private key unnecessarily.
- Verify connectivity after renewal and identify devices that remain offline or cannot be updated automatically.
Emergency replacement or suspected compromise
- Open an incident record and identify the affected certificate, private key, services, and owner.
- Restrict access to the suspected key and preserve relevant logs and configuration evidence.
- Determine whether revocation is required under the organization’s incident policy and the certificate authority’s procedures.
- Generate a new key pair when appropriate; avoid reusing a key that may be exposed.
- Issue and deploy the replacement certificate, then test every known dependency.
- Check revocation status and document the time, method, result, and remaining exposure.
For OCSP, CRL, and common validation errors, see How to Check a Certificate Revocation Status.
What to double-check
Before closing a renewal or replacement task, compare the intended change with the deployed result. A certificate can be valid while still being unusable for the target service.
- Hostname coverage: Confirm the requested hostname is covered by the subject or subject alternative names. Do not assume a similarly named certificate is interchangeable.
- Chain delivery: Check that required intermediate certificates are presented or trusted in the correct order.
- Key pairing: Verify that the certificate matches the private key installed at the termination point.
- Algorithm compatibility: Confirm that servers, clients, devices, and integrations support the selected key and signature algorithms.
- Deployment scope: Check every active node, region, cluster, gateway, and failover environment, not just the first endpoint tested.
- Monitoring: Confirm that expiration alerts, ownership routing, and escalation paths still work after the change.
- Evidence: Save the certificate fingerprint, validation result, deployment time, approver, and related change or incident record.
For signed files rather than network certificates, the same discipline applies: identify the signer, validate the signature, check the trust chain, and confirm that the document has not changed. The digital signature verification guide covers that separate but related workflow.
Common mistakes
- Relying on filenames: Filenames can be duplicated, changed, or disconnected from the service using the certificate. Use fingerprints, serial numbers, and deployment locations.
- Tracking only public certificates: Internal, device, client, signing, and test certificates can also cause outages or trust failures.
- Assigning ownership to a platform: A system may host a certificate, but a team must still be accountable for renewal and testing.
- Renewing without testing dependencies: Mutual TLS, pinned certificates, custom trust stores, and older devices may reject a replacement even when browsers accept it.
- Assuming automation is complete: An automated request does not guarantee successful issuance, installation, reload, or monitoring. Test the entire path.
- Deleting before confirming retirement: Remove retired certificates and keys only after checking backups, disaster-recovery procedures, integrations, and audit requirements.
- Ignoring revocation records: Mark a certificate as revoked or retired in the inventory and preserve the reason and date.
When to revisit
Review this runbook before seasonal planning cycles, scheduled renewal reviews, audits, infrastructure migrations, domain changes, and major platform or workflow changes. Revisit it immediately after a certificate-related outage, suspected key exposure, certificate authority change, or move from manual renewal to automation.
At each review, confirm that the inventory fields still match the environment, alert thresholds remain appropriate for the organization’s renewal lead time, and documented procedures reflect the current certificate issuance platform and deployment architecture. Reassess validity periods and algorithm requirements against current organizational policy and supplier guidance rather than treating an old setting as permanent.
To make the next review actionable, assign an owner to every inventory record, sort records by expiration date and risk, test one representative renewal path, and close any certificate with an unknown location or owner. Then compare the inventory with external discovery, configuration repositories, and service maps. A small, verified inventory is more useful than a large list nobody trusts.
