ARI Readiness Guide

1Client Polls renewalInfo

Your ACME client constructs an ARI CertID from the certificate's Authority Key Identifier (AKI) and serial number, then sends an unauthenticated GET request:

GET {directory.renewalInfo}/{ARI-CertID}

# Example:
GET https://acme-v02.api.letsencrypt.org/get/ari-certID/
  aYhDn6RYOi9LQPRvMi-nqWJ1kk00YFNXBgWv3YCb1nw.AIdlQyE

2CA Responds with suggestedWindow

The CA returns a renewal window — start and end timestamps — indicating when the certificate should be renewed. The response also includes a Retry-After header telling the client how often to re-poll.

HTTP/1.1 200 OK
Content-Type: application/json
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2026-06-15T00:00:00Z",
    "end": "2026-06-16T00:00:00Z"
  }
}

3Client Selects a Random Time Within the Window

The RFC specifies selecting a uniformly random time within the suggestedWindow to spread renewal load across the CA's infrastructure and avoid thundering-herd spikes. If the window has already passed, skip the random selection and renew immediately.

4Client Sends New Order with replaces Field

When renewing in response to an ARI signal, the client includes a replaces field identifying which certificate is being replaced:

POST /acme/new-order
Content-Type: application/jose+json

{
  "identifiers": [
    { "type": "dns", "value": "example.com" }
  ],
  "replaces": "aYhDn6RYOi9LQPRvMi-nqWJ1kk00YFNXBgWv3YCb1nw.AIdlQyE"
}

5Client Re-polls After Retry-After Interval

Even after successful renewal, the client continues polling for all managed certificates. The loop must run continuously — not just once after renewal.

Certbot (v4.1.0+)

The most widely deployed ACME client. ARI support landed in v4.1.0 (June 2025). It checks the renewalInfo endpoint during certbot renew and will trigger early renewal if the suggested window has passed.

Two limitations: (1) it only checks when the cron job or systemd timer fires — if that's every 12 hours or weekly, there's a gap between the CA's signal and your response; (2) it does not send the replaces field, so the CA can't revoke the predecessor immediately or waive rate limits.

Caddy

Runs as a long-lived process with full ARI support including the replaces field. This is the closest to the RFC's intended client architecture — it polls continuously rather than on a cron schedule, responding to emergency signals in near-real-time.

Certbot

1. Verify your version (must be 4.1.0+):

   certbot --version

2. Check your systemd timer frequency:

   systemctl list-timers certbot*

3. The default Certbot systemd timer runs twice daily — this is adequate for most scenarios.
4. If running via cron, verify your schedule:

   crontab -l | grep certbot

5. Recommendation: Increase to every 6 hours if managing critical services, matching Let's Encrypt's Retry-After value:

   # Add to crontab:\n0 */6 * * * certbot renew --quiet

6. No additional configuration is needed — ARI is enabled by default when the CA supports it.

Caddy

ARI is enabled by default. No configuration needed. Caddy manages certificates automatically when you configure HTTPS. Verify your version with:

caddy version

acme.sh Users — Migration Path

• Short term: Increase cron frequency to every 6 hours and monitor your CA's incident channels manually.
• Medium term: Evaluate migrating critical certificates to a client with ARI support (Certbot, Caddy, or Lego).
• The --renew --force command is your emergency fallback, but it requires manual identification of affected certificates.

cert-manager (Kubernetes) — Workaround

• No native ARI support yet — monitor cert-manager issue #6010.
• Workaround: Monitor Let's Encrypt community forum and CA incident channels; use kubectl cert-manager renew to force renewal of specific Certificate resources:

  # Force renew a specific certificate:\nkubectl cert-manager renew my-certificate -n my-namespace\n\n# Force renew all certificates in a namespace:\nkubectl cert-manager renew --all -n my-namespace

• For critical workloads, consider running a sidecar or CronJob that polls the ARI endpoint externally and triggers cert-manager renewals via the API.

1Check That ARI Is Being Used

For Certbot, run a dry run and look for ARI-related log messages showing renewal timing based on ARI vs. static expiry threshold:

certbot renew --dry-run -v 2>&1 | grep -i 'ari\|renewal\|window'

2Verify Your Polling Interval

Match or exceed the CA's Retry-After value. For Let's Encrypt, that's 6 hours. If your certbot renew cron runs less frequently, you have a gap.

3Simulate an Emergency Renewal

Force-renew a non-critical certificate and time the end-to-end process:

time certbot renew --force-renewal --cert-name your-domain.com

From command execution to new certificate deployed — how long? If that number is measured in hours for a single certificate, multiply by your total certificate count.

4Check Certificate Deployment Automation

ARI handles the renewal trigger, but does your post-renewal hook reload the web server? Does your load balancer pick up the new cert automatically? Check your deploy hooks:

# Certbot post-renewal hooks:\nls /etc/letsencrypt/renewal-hooks/deploy/\n\n# Or check renewal config:\ngrep -r 'post_hook\\|deploy_hook' /etc/letsencrypt/renewal/

5Monitor Your CA's Incident Channels

ARI is the signal mechanism. Your CA's community forum and Bugzilla are the context mechanism. You need both. Subscribe to the Let's Encrypt community forum, Mozilla Bugzilla CA compliance, and your commercial CA's status page.