Most certificate lifecycle management is free. The part that costs money was never a tool.
Search for certificate lifecycle management tools and you get five kinds of product that answer five different questions. Most teams need two of them, both free, and the certificates that cause the outages sit outside all five.
An ACME client is the right answer for most public certificates
If a certificate is publicly trusted and the host can answer an ACME challenge, renewal is a solved problem. On a server that is certbot, an EFF project that obtains and renews Let's Encrypt certificates, and the client Let's Encrypt itself suggests starting with. On Kubernetes or OpenShift it is cert-manager, which is open source and renews certificates before they expire from ACME, Vault or a private CA.
We ran this in our own lab rather than take it on trust. certbot issued certificates through both the HTTP-01 and DNS-01 challenges against a test ACME server, then renewed both with fresh serial numbers and no human step. That loop is what makes the CA/Browser Forum's schedule survivable. Public TLS lifetimes fall to 100 days in March 2027 and 47 days in March 2029. That is about eight renewals a year, and a calendar reminder does not keep up.
If every certificate you have can go through an ACME client, stop here. You do not need anything else on this page.
A CT-log monitor tells you what was issued in your name
Every publicly trusted certificate is written to the Certificate Transparency logs. A CT monitor watches those logs and tells you when a certificate appears for one of your domains, including the ones issued by a team that never mentioned it.
SSLMate's Cert Spotter has an open-source edition that does this without a database, under the MPL-2.0 licence. Searching the logs by hand for your domains costs nothing either.
What a CT monitor cannot see is anything private. Internal CAs, self-signed certificates and device certificates never reach a public log, so the monitor's picture is complete for public issuance and empty for the rest.
Expiry monitors and discovery tools answer "when" from the outside
The next class connects to endpoints you list, reads the certificate each one serves, and warns you before it expires. Some also discover hostnames for you. KeyChest is the well-known example: a dashboard of expiry dates, sub-domain discovery and spot checks, run by its authors as a free service.
Use one if you have nothing doing this today. It is the cheapest fix in this whole post.
Its limit is the list. A monitor watches the endpoints it knows about. We built a four-endpoint estate in the lab and swept it read-only. It held a certificate that had expired 203 days earlier and was still serving, an mTLS certificate two days from expiry, and a ten-year self-signed vendor console certificate. A tool keyed to a known list would have shown none of the three, because none of them was on it.
Enterprise CLM platforms reach inside, once someone wires them in
Keyfactor Command, AppViewX CLM and Palo Alto Networks' NGTS (the product previously sold as Venafi TLS Protect) are the platforms behind the head search terms. Their published material describes discovery across public and private CAs, cloud and network endpoints, plus automated renewal and installation through agents and integrations. None of the three publishes a price; each asks you to request a quote or a demo.
These are the only tools in this list that are built to touch internal CAs and the devices certificates live on. They earn their cost in an estate large enough to justify a team running the platform.
The catch is in that last clause. A platform renews a certificate on an appliance once someone has built and maintains the connector for that appliance, with credentials that work. Discovery lists a certificate; the platform still needs a person to say whose it is.
Pick by the question you need answered
| The question | Tool class | Examples | Cost |
|---|---|---|---|
| Can this public certificate renew itself? | ACME client | certbot, cert-manager | free, open source |
| What has been issued for my domains? | CT-log monitor | Cert Spotter (open source) | free |
| When does each known endpoint expire? | Expiry monitor | KeyChest | free service |
| What is out there that I have not listed? | Discovery | KeyChest, CLM platforms | free (KeyChest) or quote only |
| Who renews the internal CA, appliance and mTLS certificates? | none |
If your estate is mostly public web endpoints, the first three rows cover it. Start there.
Every class stops at the certificate with no named owner
Look at the last row again. Take an internal CA root that expires in fourteen months. It is visible to a discovery tool and a CLM platform. Neither will renew it, rebuild the hierarchy under it, or reissue everything it signed. A load balancer with no API can be listed and alerted on, and someone with a login still has to upload the new certificate. An mTLS certificate between two services can be found, and the renewal still needs someone who knows what breaks when it changes.
That remainder is small, and it is where the outages come from, because a warning names a date and no person. We wrote about why those certificates have no owner separately. The short version is that ownership is a decision someone makes, and no product can make it for you. That part is engagement work: the remediation itself, and a named owner for each certificate when it is done.
See your public certificates first
If you want the CT-log half of this for your own domain, we will send it. Enter a domain you own and you get its public Certificate Transparency profile by email. It covers issuers, how many names, how much already renews through ACME, and what the 47-day schedule does to that pattern. It reads public logs only and never connects to your systems.
