A TLS certificate lifecycle has seven stages: generate a key pair, request a certificate, prove control of the name, receive the issued certificate, deploy it, monitor it, then renew or revoke it. With public certificate lifetimes shrinking, doing those steps by hand no longer scales.
What happens at each stage?
1. Key generation. The server creates a private key and keeps it. The private key never leaves the system that needs it, and it should be unreadable to people who do not operate the service.
2. Request. The server sends a certificate signing request that includes the public key and the names it wants covered.
3. Validation. The certificate authority checks that the requester controls those names, typically by a file placed on the web server, a DNS record, or an email. Public CAs follow the CA/Browser Forum Baseline Requirements.
4. Issuance. The CA signs and returns the certificate. RFC 5280 defines the certificate profile, including the validity period with its start and end times.
5. Deployment. The certificate and chain are installed on every system that terminates TLS: web servers, load balancers, proxies, mail servers, appliances.
6. Monitoring. Track expiry, chain correctness and which hosts present which certificate.
7. Renewal or revocation. Replace the certificate before it ends, or revoke it early if the key may be compromised. RFC 5280 also defines certificate revocation lists.
Why is automation now necessary?
The Baseline Requirements set a maximum validity of 200 days for subscriber certificates issued from 15 March 2026. The same document schedules 100 days for certificates issued from 15 March 2027, and a limit of 47 days from 15 March 2029, expressed there as a SHOULD NOT above 46 days and a MUST NOT above 47. It also shortens how long a previous domain validation can be reused.
A team that renewed once a year now renews at least twice, and soon more than eight times. Manual calendars, shared mailboxes and tickets break at that frequency.
How does ACME help?
RFC 8555 defines the Automated Certificate Management Environment, a protocol for an agent on your server to request, validate, install and renew certificates without a person. The agent proves control of a name by completing a challenge set by the CA, then fetches the certificate. You schedule it to run daily and renew when a certificate is close to its end.
ACME does not remove the need for design choices. You still decide where private keys live, who may request certificates for which names, and what happens when renewal fails.
What goes wrong in practice?
- A certificate is installed on nine of ten load balancers, and the tenth expires.
- A wildcard certificate is copied to many systems, so one compromise exposes all of them.
- An internal service uses a long lived certificate from a private CA that nobody tracks.
- Renewal works, but the service does not reload, so the old certificate stays in memory.
- A person who knew the process leaves.
A constructed example
A company has a certificate on its public API, issued manually every year. The owner is on leave when it expires, and mobile clients start failing at 06:00.
After the rebuild, an ACME client runs on the load balancer, renews at two thirds of the validity period, reloads the service, and posts a message to a channel. A separate monitor checks the live certificate from outside and pages when fewer than 14 days remain. The first alert is a warning, not an outage.
How to check or apply this
- Inventory every certificate by scanning your address space and certificate transparency logs for your domains.
- Record owner, issuer, expiry, and where the private key is stored.
- Move public certificates to automated issuance and renewal with ACME or your platform's equivalent.
- Restrict which systems may request certificates for which names.
- Prefer one certificate per service over one wildcard shared widely.
- Reload services automatically after renewal and verify with an outside check.
- Alert on remaining validity, not just on expiry.
- Write a revocation procedure and test it once.
Quick check
Do shorter lifetimes make certificates less secure to manage?
They reduce exposure after a key leak, since stolen keys stop working sooner. The cost is operational, which automation addresses.
Is revocation reliable?
It helps but is not instant everywhere, because clients differ in how they check it. Short lifetimes and quick key replacement are the stronger protection.
Sources
- RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 8555, Automatic Certificate Management Environment (ACME)
- CA/Browser Forum Baseline Requirements
Last reviewed: 18 October 2026.
