ACME Renewal Information Simplifies Cert Renewal as Short-Lived Certs Go Mainstream
In December 2025 Let's Encrypt announced shortening certificate lifetimes from 90 to 45 days; in January 2026, six-day and IP address certificates became generally available to all subscribers. Shorter lifetimes make automated renewal an operational lifeline rather than a nice-to-have. In this context the ACME Renewal Information (ARI, RFC 9773) protocol became significantly more valuable, and Shopify shared how it uses ARI to renew certificates for millions of merchant domains more reliably in March 2026.
The Problem with Fixed Renewal Thresholds
Shopify originally used a static threshold: renew at day 60 of the 90-day lifetime (30 days before expiry), with a random 0-72 hour delay to spread load. This static logic has three weaknesses:
- No rapid revocation response: it is unaware of revocations entirely.
- Brittleness to lifetime changes: a hard-coded 30-day threshold breaks when lifetimes change, such as the move to 45-day certificates.
- Imperfect load distribution: despite random jitter, massive renewal bursts can still occur.
How ARI Works
ARI provides a new standard interface for renewal: clients call the /renewal-info endpoint, and the CA returns a suggested renewal window, for example:
{
"suggestedWindow": {
"start": "2026-02-03T04:00:00Z",
"end": "2026-02-04T04:00:00Z"
}
}
The client picks a random time within the window and, in new_order, passes the original certificate identifier via the replaces key, which can grant higher priority or bypass rate limits during the window. Critically, clients can poll the ARI endpoint for updated timestamps, letting the CA dynamically change renewal timing on revocation events without hard-coded expiry thresholds.
Two Renewal Models Side by Side
Comparing ARI with fixed-threshold renewal makes the difference obvious:
| Dimension | Fixed-threshold renewal | ARI-driven renewal |
|---|---|---|
| Timing | Client hard-codes "N days before expiry" | CA returns a suggested window |
| Revocation response | Blind until the next scheduled task | Polling lets the CA re-issue early |
| Lifetime changes | Requires code and a release | Clients adapt automatically |
| Load coordination | Approximated with random jitter | CA schedules against global load |
| Rate limits | All renewals treated equally | In-window requests get priority |
That table explains why Shopify handed the timing decision to the CA: at a scale of tens of millions of certificates, the CA's global view beats any local estimate, and maintaining custom logic that can go stale is riskier than letting the protocol do the work.
Setting It Up with Certbot and acme.sh
For ordinary site owners, moving to ARI requires almost no code changes. Mainstream clients such as Certbot and acme.sh already support ARI; the real work is keeping the client up to date and turning renewal into a frequent, de-duplicated scheduled task:
# /etc/systemd/system/certbot-renew.timer
[Unit]
Description=Run certbot renew twice a day
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
Two triggers a day plus RandomizedDelaySec, layered on top of the client-side randomization inside the ARI window, means dozens of servers pointing at one domain will not all hit the CA endpoint at the same second. When a renewal fails, systemctl status certbot-renew.timer and the logs pinpoint the problem quickly; wiring a failure notification script on top keeps "expired certificate" incidents from happening at 3 a.m.
The Security Payoff of Short-Lived Certificates
Moving from 90 to 45 days, and optionally to six days, narrows the window in which a compromised or abused key can be exploited. Let's Encrypt clarified that renewals do not count toward rate limits, so 45-day certificates do not trigger new-subscriber caps, and mainstream ACME clients such as Certbot already support six-day and IP address certificates. For sites with fully automated renewal, short-lived certificates deliver security benefits at near-zero cost. One caveat: six-day certificates squeeze the tolerance for unattended renewal to its limit, so the reliability of your alerting and retry logic matters more than the certificate itself.
What It Means for Websites
If you still renew on a fixed number of days before expiry, switching to ARI-driven renewal is strongly recommended. Start with Let's Encrypt SSL setup and Certbot auto-renewal, choose the right type with SSL certificate types, and plan holistically with the SSL certificate guide. More content is in the Security/SSL category.
Reference: ARI specification RFC 9773 https://www.rfc-editor.org/rfc/rfc9773; source https://letsencrypt.org/2026/03/17/acme-renewal-information-ari