Certificate lifecycle management: what to automate and how

8 min readUpdated Oct 2026

Certificate lifecycle management is the work of knowing every certificate you run, who answers for it, and how it gets replaced, on schedule or at short notice. SSL certificates pass through the same stages: request, issuance, service on a server, then expiry, replacement or revocation. Spread hundreds of them over load balancers, mail servers and devices, and managing certificates becomes an inventory problem: a certificate missing from the list is one nobody will replace.

NIST's practice guide on TLS server certificate management describes a formal certificate management program ^[2]. One protocol carries the idea in its name: ACME, the Automatic Certificate Management Environment of RFC 8555, automates verification and issuance, and also handles other certificate management functions such as revocation ^[1].

Short notice: a public authority must revoke within 24 hours after a key compromise, and within 5 days if the certificate was not issued according to the Baseline Requirements ^[3]
Shorter lifetimes: 47 days at most for public certificates issued from 15 March 2029 ^[3]
Discovery: Certificate Transparency logs record certificates as they are issued or observed ^[4]
Issuance control: a CAA record names the authorities allowed to issue for a domain ^[5]
Automation: ACME, and renewal windows the authority suggests (ARI) ^[1]^[6]

What goes wrong without it

Three kinds of failure, and only the first is about dates.

Expiry nobody saw coming. A certificate on a host no one watches runs to its end date, and clients reject it from that moment. The maximum lifetime of public certificates keeps falling in steps ^[3], so every certificate comes up for replacement more often. The schedule, and what a renewal can reuse, is in the renewal guide of this section.
Replacement on someone else's clock. An authority that learns of a problem with a certificate has a fixed time to revoke it, even when the fault is its own. The site then needs a new certificate within days, whatever the old end date said.
Certificates you did not issue. A test host left running, an appliance with its own certificate, a name a contractor set up, or a certificate issued to someone who should not have one. You cannot replace or revoke what you do not know exists.

The inventory: what each row records

The inventory has one row per certificate in service, with enough columns to act on it without investigating first.

What each inventory row records
Record	Why it is needed
Names covered	the subject alternative name list decides which hostnames fail if this certificate lapses
Where it is served	host and port, load balancer, CDN or device: every place the replacement has to reach
Issuer and chain	which authority signed it and through which intermediate. A new certificate can arrive under a different intermediate, so the chain certificates a server sends have to change with it
End date	the day of expiry, and so the latest day it can be replaced
Key type and location	what a compromise would expose, and what the replacement has to match
Owner	a person or team who answers when it fails
Replaced by	an ACME client, a platform, or a manual process with a named person
Validation route	the DNS record or HTTP path the authority checks; a new DNS provider or a redirect breaks it

Generate the list rather than typing it. Export what each ACME client, platform and authority account knows, and compare the result with what the servers actually present. A list kept by hand drifts.

Finding certificates you did not know about

Discovery fills the inventory from four directions, and each one finds certificates the others miss.

Certificate Transparency logs. RFC 6962 describes public logs of TLS certificates and monitors that "check whether domains they are responsible for have had certificates issued that they did not expect" ^[4]. Search the logs for your domains. An entry you cannot place is either a forgotten service or a certificate someone else obtained.
The servers. Ask each host and port which certificate it presents; the commands are in how to check an SSL certificate. Include mail, APIs and internal dashboards, not only the website.
Authority accounts and clients. Order history at every authority you use, and the list each ACME client keeps of the certificates it manages.
Configuration. Server and proxy configuration names the files in use, such as ssl_certificate in nginx or SSLCertificateFile in Apache, which ties a row to a file on disk.

A private authority is a separate case. Its certificates are trusted only by machines where its root has been installed, and its own issuance records are where they get listed.

Policy: which certificates should exist

Without a policy, discovery produces a list but no findings: nothing says which entries are wrong.

Allowed authorities. A CAA record, defined in RFC 8659, lets the domain holder name the authorities authorized to issue for that name ^[5]. A public authority has to check it before issuing, and must not issue when the request conflicts with it ^[3]^[5]. Name the same authorities in the policy, so that a log entry from any other certification authority is a finding.
Validation and DNS access. Record which validation method each domain uses and who holds the DNS credentials. Whoever controls DNS can pass domain validation.
Keys. Which key algorithms you accept, and the rule that a replacement after a compromise gets a new key.
Owners. No certificate in service without an owner in the inventory.

What to automate, and what stays a decision

Everything that repeats per certificate can run without a person. What to trust, and whether a key is compromised, stays with people.

Which certificate tasks to automate
Task	Automate?	How
Key and request	yes	the client can create a new key and certificate signing request for each order ^[1]
Validation and issuance	yes	ACME ^[1]
Deployment and reload	yes, as its own step	the new files reach every place in the inventory row, and the server reloads
Timing	yes	the client's schedule; ARI, defined in RFC 9773, lets the authority suggest when to renew and ask for renewal ahead of a mass revocation ^[6]
Expiry monitoring	yes, kept separate	an outside check of each served certificate, run by something other than what replaces it
Revocation request	possible	ACME can request revocation ^[1]; deciding that a key is compromised is a person's call
Authorities, policy, owners	no	decisions, recorded in the policy and the inventory

How scheduled renewal fails quietly, and how to test it, is covered on the renewal automation page of the ACME section.

Replacing a certificate at short notice

The Baseline Requirements set how fast a public authority has to revoke, counted from receipt of the problem report, not from a date that suits the site ^[3]. Selected cases from §4.9.1.1, its list of revocation reasons:

Revocation deadlines under the Baseline Requirements
Revoke within	When, for example
24 hours	the private key was compromised; the request was not authorized; the domain validation can no longer be relied on, including a CAA check the authority got wrong
5 days, 24 hours recommended	the certificate was not issued according to the Baseline Requirements or the authority's own policy; information in it is inaccurate; the key no longer meets the size and parameter rules

Several are the authority's mistakes, not the site's, and the certificate goes anyway. Short-lived certificates are the exception. For those issued since 15 March 2026 with a validity period of 7 days or less, the deadlines above do not apply, and an authority may choose not to support revoking them ^[3].

Being ready means any row of the inventory can be replaced within a day: the route works, the owner can be reached, and the new certificate reaches everywhere the old one is served. Rehearse it on one certificate. Replace first and revoke afterwards, except after a key compromise; the guide to revoking a certificate in this section explains that order.

FAQ

What is certificate lifecycle management?

Keeping every certificate in service known, owned and replaceable: an inventory, discovery of certificates not yet on it, a policy for which ones should exist, and automated issuance, deployment and replacement.

What is a certificate manager?

Any tool that keeps track of certificates, and the name covers very different scopes. On Windows, certmgr.msc is the console that opens the certificate store of the current user. cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift clusters and renews them before they expire. A certificate management system for a whole organisation adds the inventory, discovery and policy described on this page. ^[8]^[7]

What is a certificate management program?

A formal program for managing an organisation's TLS server certificates, the term NIST's practice guide uses. Its example implementation shows how to prevent, detect and recover from certificate-related incidents. ^[2]

Sources

IETF, RFC 8555, Automatic Certificate Management Environment (ACME).
NIST, SP 1800-16, Securing Web Transactions: TLS Server Certificate Management.
CA/Browser Forum, Baseline Requirements for TLS Server Certificates (version 2.3.1): §1.2.2 relevant dates, §6.3.2 maximum validity period, §1.6.1 definition of Short-lived Subscriber Certificate, §4.2.2.1 CAA record processing, §4.9.1.1 reasons for revoking a subscriber certificate, §4.9.5 time within which a CA must process the revocation request.
IETF, RFC 6962, Certificate Transparency.
IETF, RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record.
IETF, RFC 9773, ACME Renewal Information (ARI) Extension.
cert-manager, documentation.
Microsoft Learn, How to: View certificates with the MMC snap-in.