Certificate lifecycle management

Every certificate you run has an expiration date. Managing the renewals and deployments at scale is what CLM does.

Certificate lifecycle management (CLM) is the practice of tracking every TLS/SSL certificate across your infrastructure through its entire life (discovery, issuance, deployment, monitoring, renewal, and revocation) so none of them expire unexpectedly and take a service down with them.

This page explains what each stage involves and what to look for in a solution. If you already know you want it automated:

Start free trial See how CertKit works

What is certificate lifecycle management?

A certificate isn't a set-and-forget asset. It's issued for a fixed period, it has to be installed in the right place and format on every system that serves it, and it has to be replaced before it expires, over and over, for the life of the service. Certificate lifecycle management is the discipline of doing that reliably across all of them: knowing what you have, keeping each one valid, and never being surprised by an expiry.

The certificate lifecycle

 ┌──────────┐   ┌───────┐   ┌────────┐   ┌─────────┐   ┌───────┐   ┌────────┐
 │ Discover │──►│ Issue │──►│ Deploy │──►│ Monitor │──►│ Renew │──►│ Revoke │
 └──────────┘   └───────┘   └────┬───┘   └─────────┘   └───┬───┘   └────────┘
                                 │                         │
                                 │                         │
                                 └────────────◄────────────┘

The lifecycle is a loop, not a line. Every renewal re-runs deployment and monitoring.

Small environments handle this by hand, with a spreadsheet, a calendar reminder, and a renewal afternoon once a year. That breaks down as the number of certificates grows and the certificate validity period shrinks.

Certificate management vs. certificate lifecycle management

The two terms get used interchangeably, and most of the time that's fine. Certificate management is the broad practice: keeping track of the digital certificates your organization runs and making sure they stay valid. Certificate lifecycle management is the specific discipline of doing that across every stage, from discovery to revocation, without a person driving each step.

The distinction matters when you're buying. Plenty of certificate management software inventories what you have. Plenty of ACME clients renew what they issued. Neither one manages the lifecycle. Something still has to install the certificate on every system that serves it, confirm it landed, and do the whole thing again on the next cycle.

Centralized certificate management is what changes at scale: one inventory, one renewal engine, and one place that knows the state of every certificate, instead of per-server scripts and a spreadsheet trying to reconcile them.

The six stages of CLM

1. Discovery

You can't manage a certificate you don't know about. Discovery finds every certificate issued for your domains, including the forgotten ones, by searching Certificate Transparency logs, the public record of every certificate.

How certificate discovery works

2. Issuance

Getting a certificate from a Certificate Authority. Modern issuance is automated with the ACME protocol, which proves you control a domain and returns a certificate without anyone in the loop.

Certificate issuance with ACME

3. Deployment

A certificate does nothing sitting on a filesystem or in a dashboard. It has to be installed, in the right format, on every server and appliance that serves it. This last mile is where most automation breaks, because each platform installs certificates differently.

See deployment integrations

4. Expiration monitoring

Knowing the state of every certificate in real time: what is expiring, what failed to renew, what is installed but serving the wrong certificate. Good monitoring warns you before an expiry becomes an outage, not after.

SSL certificate monitoring

5. Renewal

Replacing a certificate before it expires, then redeploying it everywhere it lives. With shorter lifetimes this stage dominates the workload. It happens constantly, and every renewal re-triggers deployment and verification.

Certificate renewal automation

6. Revocation

Invalidating a certificate before its natural expiry, after a key compromise, a mis-issuance, or a decommissioned service. Revocation is rare, but it has to be possible, and you need to know which systems are affected when it happens.

Why this is getting harder, fast

Certificate lifetimes are shrinking. The 200-day maximum is already in effect, and the industry is on a path to 47-day certificates by 2029. A renewal that used to happen once a year will need to happen roughly twelve times a year, on every certificate, on every system that serves it.

At that cadence, manual renewal stops being a process and becomes a standing liability. The math is simple: more renewals times more systems equals more chances for a missed expiry.

Read about the certificate lifetime mandate

Manual vs. automated

The difference isn't effort. It's whether the work scales at all.

Manual

A spreadsheet of certificates and expiry dates, calendar reminders, and someone running OpenSSL and updating bindings by hand each cycle. It works for a handful of certificates. It fails the first time you take a vacation during a renewal window.

Automated

Certificates are discovered, issued, deployed, monitored, and renewed by a system that runs every cycle without intervention, and tells you when something needs attention. The renewal cadence stops mattering because nobody is in the loop.

What to look for in certificate management software

Not every certificate management tool covers the whole lifecycle. When you evaluate one, check that it handles all six stages. Most stop at issuance and leave deployment to you:

Discovery across your domains, not just the ones you already know about.
Automated issuance and renewal via ACME, without per-server credentials.
Deployment to your actual systems, the last mile to web servers, appliances, and Windows services, not just a download.
Monitoring and verification that confirms the right certificate is actually being served after each renewal.
An audit trail of every issuance, renewal, and deployment.

Check whether it covers private certificates too. Internal hostnames, IP addresses, and mTLS client certificates cannot come from a public CA, and they still need the same discovery, deployment, and renewal as everything else. A managed PKI puts them in the same inventory instead of a second one.

Weighing specific options? See how CertKit compares to enterprise CLM platforms like Venafi, Keyfactor, and Sectigo, and to open-source ACME clients like certbot and win-acme.

How CertKit handles the full lifecycle

CertKit covers all six stages from one account: centralized certificate management, rather than a renewal script running on every host. It discovers your certificates through Certificate Transparency logs, issues and renews them centrally over ACME using delegated DNS validation (one CNAME, no per-server credentials), and the CertKit Agent deploys each renewal to your servers and appliances automatically, then verifies the certificate is actually being served.

Start free trial See how it works

From an operational perspective, CertKit is easy to deploy and manage. The ability to configure unique and specialized certificates is key to replacing our manual certificate processes.

Laura Thomas, Senior Central Systems Administrator, University of St. Thomas

Frequently asked questions

Do I need full lifecycle management, or just monitoring?

Most teams start with monitoring to stop surprise expiries. But monitoring only tells you a certificate is about to expire. It doesn't renew or deploy it. Full lifecycle management does the work for you. If you run more than a handful of certificates, or your lifetimes are short, automation is what actually removes the workload.

About certificate monitoring

How is this different from running Certbot or an ACME client?

An ACME client handles issuance and renewal on the one server it runs on. Lifecycle management covers the whole picture across all your systems: discovery, deployment to servers and appliances, and monitoring, from one place. You aren't managing a renewal script on every machine.

See the architecture

Is certificate lifecycle management only for large companies?

No. The trigger is the number of certificates and how often they renew, not the size of the company. Enterprise certificate management platforms are built on the opposite assumption, which is why they price and deploy the way they do. With 200-day certificates today and 47-day certificates coming, even small teams reach the point where a spreadsheet stops working.

What is the difference between PKI and certificate lifecycle management?

PKI is the trust infrastructure: the certificate authorities, roots, and intermediates that issue certificates and vouch for them. Certificate lifecycle management is the operational layer on top, covering what happens to each certificate after it exists. You can run a PKI without managing the lifecycle, and most organizations do, which is why certificates still expire in environments that have a perfectly good CA behind them.

About managed PKI

Do I have to replace my certificate authority?

No. CertKit works with Let's Encrypt, your current CA, or any ACME-compatible authority, and you are never locked in. Most teams move to free Let's Encrypt certificates once renewal is automated, but you don't have to.

How do I get started?

Start a 90-day free trial, no credit card required. Connect your domains, and CertKit discovers your certificates and begins managing the lifecycle. You get direct access to our engineering team to help you set up.

See pricing

Put the certificate lifecycle on autopilot

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing