Automate SSL Certificate Renewal with ACME & REST API
Certificate lifespans shrink to 47 days by 2029. See how ACME and REST API automation keep SSL renewals running without adding to your team’s workload.
How to Automate SSL Certificate Renewal with ACME & REST API
Manual SSL certificate renewal used to be an easy problem to defer. At 398 days’ validity, a certificate was mostly a once-a-year task: request it, install it and forget about it for most of a year. The CA/Browser Forum’s Ballot SC-081v3 lays out a fixed timeline for shrinking that window:
March 2026: 200 days
March 2027: 100 days
March 2029: 47 days
Renewal frequency in practice already outpaces what those validity ceilings alone suggest. Teams running today's common 90-day certificates typically renew at roughly two-thirds of that life, or every 60 days, about six times a year. Applying that same two-thirds pattern to a 47-day certificate suggests renewals occur about once a month, or twelve times a year.
For a developer running a single project, that's a mild inconvenience. For a platform team managing 300 certificates across servers and internal tools, the math gets scarier fast. Those 300 annual renewals amount to 3,600 renewal events per year. Even a fast renewal at three minutes each works out to about 180 hours of hands-on time, before counting the interruptions, failed validations or a certificate someone forgot to add to the tracking sheet.
Manual renewal doesn’t scale to a 47-day world, which is why teams are moving now to automate SSL certificate renewal using one of two paths: the ACME protocol or a certificate authority’s (CA’s) REST API. Here’s how each works and how to choose between them.
How ACME Automates SSL Certificate Renewal
ACME (Automated Certificate Management Environment) is the IETF-standardized protocol most CAs and automation tools use to issue and renew certificates automatically instead of relying on manual certificate management workflows. At a high level, the process involves proving domain control and then obtaining a certificate.
Domain validation happens one of two common ways. With an HTTP-01 challenge, your ACME client places a specific file at a known path under /.well-known/acme-challenge/ on your web server, and the CA checks for it over port 80. With a DNS-01 challenge, the client creates a TXT record in your DNS zone instead. This is the method to reach for wildcard certificates or servers sitting behind a firewall with no public port 80 access.
The part that actually removes the human from the loop is what happens after that first setup. Once your ACME client is configured with a challenge method and pointed to your CA, it automatically repeats the same validation and reissuance process. Some clients, like acme.sh, which defaults to ZeroSSL as its certificate authority, run on a schedule you set yourself, typically through a cron job or a systemd timer. Others, like Caddy, handle that scheduling internally as part of how they run.
The result is a certificate that stays current on its own, renewed in the background well before it expires. That automation becomes more valuable as the CA/Browser Forum shortens the period during which a completed domain validation can be reused, down to 10 days by 2029. Nearly every renewal will need a fresh validation pass rather than reusing an old one, and with ACME, that step happens automatically. Therefore, the process stays hands-off even as validation is checked more often.
How REST API Automation Handles SSL Certificate Renewal
REST API automation skips the standardized protocol altogether. Instead of installing an ACME client, your team calls the certificate authority’s API directly and builds the renewal logic yourselves.
Here is the basic flow:
Send a CSR, the file generated from your private key that tells the CA which domain you’re requesting a certificate for
Complete a validation step, commonly email confirmation, a DNS CNAME record or an HTTP file check depending on what the API supports
Pull down the signed certificate once it’s issued
Push it out to wherever it needs to run
Building it yourself takes more setup time than pointing an existing ACME client at a config file, but it buys the flexibility and direct control to shape how certificates are requested, validated and delivered. Because every step is exposed as an API call, that flexibility is easy to fold straight into workflows a team already runs:
Fits into CI/CD pipelines that need a fresh certificate issued right before a deploy
Plugs into infrastructure-as-code tools, so a new server and its certificate get provisioned together
Feeds cloud provisioning scripts that spin resources up and down without a person watching
Powers internal request portals, letting other teams request a certificate through a form instead of a ticket
None of this rules out ACME for the same use cases. It's simply a different way of getting there, and worth weighing against what your team actually needs.
ACME or REST API: Which Fits Your Team?
Most organizations start with ACME. It’s the faster path since the client ecosystem already exists. Plus, tools like acme.sh, win-acme, Certbot and cert-manager cover the vast majority of servers, containers and Kubernetes clusters without custom code. If your infrastructure looks like a typical web server or a container platform, an existing ACME client probably already fits.
REST API automation earns its complexity when a team wants more control over how these workflows run than a standard ACME client offers:
Certificate issuance triggered from inside a CI/CD pipeline
Provisioning tied to infrastructure that spins up and down on its own
Each of these can be done with ACME too. The real difference isn't whether the workflow can be automated. It's the level of customization, integration and direct control that the implementation requires, and REST APIs typically offer more of it.
REST API also suits teams that would rather own the automation code directly than depend on a third-party client’s release schedule, though that ownership comes with trade-offs. It means more control over how renewal works, but also more maintenance and operational responsibility than relying on a mature, widely used ACME client that others are already keeping up to date.
It’s worth keeping in mind that ACME and REST API aren’t mutually exclusive. Plenty of teams run ACME for the bulk of their standard server certificates and lean on the REST API for the handful of cases, like bulk issuance or custom tooling, that need programmatic control ACME wasn’t designed to give them.
Best Practices for Automating Certificate Renewal
Automation is what makes the certificate renewal problem disappear. Once it's running, a certificate renews itself quietly in the background, no reminders, no tracking sheets, no one scrambling before an expiration date. That peace of mind holds up as long as monitoring and ownership stay in the picture.
A few practices keep it that way:
Set alerts for renewal failures, not just for certificates nearing expiration, so a broken pipeline surfaces days before the certificate does
Keep a documented fallback procedure for manual issuance in case the automated path breaks and needs a stopgap
Assign a specific person or team as the owner of the automation, so a failure has somewhere to land instead of getting discovered by whoever happens to notice the outage
These habits are simple, and they’re the difference between catching a failure early and finding out about it only once something’s already down.
Start Automating with ZeroSSL
Whether your team lands on ACME, REST API or some mix of both, the underlying push is the same: certificates that renew themselves on schedule without anyone having to remember to do it. That payoff only grows as your certificate footprint does. A single project can absorb a few extra renewals a year without much friction, but a team managing certificates at scale gets the most out of never having to do this by hand again. Waiting until validity periods shrink further only makes the transition harder, since teams that automate now have years of runway to work out the kinks before 47 days becomes the default in 2029.
The best time to automate your certificates was years ago. The second-best time is before your next renewal. Create your ZeroSSL account today and start building a certificate management process that scales with your business.
