Certificate renewal automation: how to stop expiry outages

A certificate has an expiry date. The outage starts earlier, when the service is still presenting the old certificate and the only install path is a person with a ticket.

Certificate renewal automation is the job of closing that gap on a schedule you do not have to remember. Issuing a new file is one step. The service has to be serving the new certificate, with a chain clients will accept, before the old one dies.

Larger certificate lifecycle platforms, ACME clients, and smaller automation tools already renew and redeploy certificates. The useful question is narrower: can you see the inventory, tell that a renewal failed, and get the new certificate onto the firewall, the Windows host, or the web server without a manual upload?

Expiry is an operations failure

Teams that "watch certificates" often watch a spreadsheet, a CA portal, or a single load balancer. The hostname that fails is the one that was never on the list: a VPN portal, an admin interface on a firewall, a remote desktop gateway, a name that was added during a cutover and never written down.

Two public incidents show the two failure modes, and neither is a product testimonial.

The Bank of England's RTGS and CHAPS Annual Report 2024/25 records a 91-minute disruption to CHAPS settlement on 31 July 2024, caused by an expired certificate in the Bank's IT infrastructure. This is a public incident report, not a claim that a particular product would have prevented it.

On 26 December 2025, Bazel users experienced certificate-expiry errors. EngFlow's January 2026 writeup describes an automatic renewal failure without notifications and restoration about twelve hours after the issue was first reported. A renewal job that fails quietly can still lead to expiry.

Monitoring that only pages when a certificate is inside 30 days does not catch a renewal that already failed. You need the attempt, the error, and a check of what the live service is presenting.

Issuance, renewal, and deployment are different jobs

Stop treating these as one checkbox.

• Domain control and the order with the certificate authority. For public TLS, that is usually ACME.
• The new certificate and chain, matched to a private key that never had to travel to a vendor's cloud.
• Installation on the thing that terminates TLS: firewall, VPN portal, IIS or RDS, NGINX, Apache, HAProxy.
• A live check that the service came back presenting that certificate, and a rollback if it did not.

Certbot on a Linux web server covers the first three for that one host, when someone already wired the reload. It does not install a FortiGate, a Palo Alto gateway, or an IIS binding. An email from the CA that says "your certificate renewed" does not either.

What a closed loop looks like

A loop you can operate has five states you can name out loud.

1. The certificate is in an inventory, with the hostname, the device, and the expiry.
2. Something attempts renewal before expiry, and a failure is visible. Silent success is not a status.
3. The new certificate is delivered to the network where the key lives.
4. The device config changes, and the previous certificate is still available.
5. A check against the live service confirms the certificate clients see. If that check fails, the previous certificate is restored.

If any state is "someone will do it," you still have a manual renewal process with extra software around it.

Why appliances fall out of ordinary ACME clients

Public web servers picked up ACME early because the process and the install target are the same machine. Firewalls and Windows roles are different. The certificate often protects a VPN portal, a management interface, or a gateway that is not the box running your ACME client. The install is an API call, a file upload, and a commit, followed by a check that the portal still answers.

That is why "we use Let's Encrypt" and "our firewalls renew themselves" are different sentences. The authority can be automated while the appliance install is still a change window.

Certonomy's published workflow starts with a CNAME setup. That delegation enables fresh domain validation when an ACME order requires it; it is not permanent proof of domain control. An on-site agent creates the private key and keeps it there. The workflow then covers the ACME order, delivery to the agent, installation, a live check, and rollback if verification fails. Read the DNS validation guide for the challenge and delegation details.

Peers automate renewal and redeploy too. This is the loop Certonomy actually runs, not a claim that nobody else renews a certificate.

What shorter lifetimes change

Public TLS issued on or after 15 March 2026 is capped at about 200 days under CA/Browser Forum ballot SC-081v3. Certificates issued on or after 15 March 2027 drop to 100 days, and certificates issued on or after 15 March 2029 drop to 47 days. Forty-seven days is not the maximum today. The schedule, and what to do with it, is in TLS certificate lifetime changes.

The operational effect is arithmetic. A fleet you renew twice a year becomes a fleet you renew about every three months, then about every month. The install step that was an occasional ticket becomes the job.

What to put in place before the next step-down

• One inventory that includes appliances, not only the public website.
• An owner for each name, and a renewal path that is not that person's calendar.
• A failed-renewal alert. Expiry alerts alone miss the Bazel failure mode: the job ran, or was supposed to, and nobody was told.
• A deployment step for every place TLS terminates. See automatic certificate deployment.
• A rollback you have used on purpose, not a wiki page titled "in case of emergency."

See how it works on the product page: domain validation, the on-site agent, ACME, then push, verify, and rollback.