ACME, ARI, and Surviving 47-Day Certificates

The public certificate lifecycle is collapsing. From 200 days today, to 100 days in March 2027, to 47 days in March 2029. The era of "renew once a year, put it in the calendar" is over. This is a practical guide to the automation stack that replaces it — and the monitoring you still need on top.

The Shrinking Certificate Lifespan

Under CA/Browser Forum Ballot SC-081, the maximum public TLS certificate lifetime is collapsing on a fixed schedule. By 2029, manual issuance is operationally impossible:

Why the Lifetime Cuts Happened

Three things drive shorter certificate lifetimes, and they're all rational:

ACME: The Protocol You're Already Using

ACME (Automated Certificate Management Environment, RFC 8555) is the protocol between your server and a CA. Let's Encrypt invented it; everyone now uses it. BuyPass, Google Trust Services, ZeroSSL, AWS Private CA, Cloudflare, Sectigo, and Microsoft Azure Key Vault all expose ACME endpoints.

The handshake, step by step

Modern clients do all of this in one shell command and a cron entry — but under the hood, every issuance and renewal runs the same loop:

Picking a client

HTTP-01 vs DNS-01: Pick One

Both challenges prove you control a hostname — they just put the proof in a different place:

ARI: The New Renewal Signal

ACME Renewal Information (ARI), standardised as RFC 9773 in 2025, is the most important addition to the protocol since launch. Before ARI, clients renewed on a fixed schedule — usually at two-thirds of the certificate lifetime. That was fine for predictable 90-day Let's Encrypt certs, but it breaks down for short-lived certs and especially for emergency rotations.

What ARI does

The CA exposes a per-certificate endpoint that returns a JSON object containing a suggestedWindow — the earliest and latest times your client should renew. The client polls the endpoint, and renews when it falls inside the window.

GET /acme/renewal-info/<cert-id>

200 OK
{
  "suggestedWindow": {
    "start": "2026-06-01T00:00:00Z",
    "end":   "2026-06-08T00:00:00Z"
  },
  "explanationURL": "https://letsencrypt.org/docs/incident-..."
}

Why it matters

• Mass-rotation events become safe. When a CA needs to revoke a batch of certificates (e.g. an incident, a key-ceremony rotation), it can advance the suggested window for affected certs. Your client renews automatically. The only reason you'd know an incident happened is the email.
• Load is spread. The CA returns staggered windows, so renewals don't pile on identical schedules every 60 days.
• It's free and lossless. Even if ARI is unavailable, the client falls back to its default schedule. There's no downside to enabling it.

Let's Encrypt has supported ARI in production since 2024. Google Trust Services, Sectigo, and Smallstep enabled it through 2025. Make sure your client is recent enough to use it.

MPIC: What Changed in Validation

Multi-Perspective Issuance Corroboration (MPIC) became mandatory under the CA/Browser Forum Baseline Requirements in March 2025. CAs must now validate domain control from at least two geographically diverse network perspectives, with a third for high-risk issuance.

For most users this is invisible. For two groups it matters:

• Self-hosted DNS with regional anycast quirks — if your _acme-challenge propagation is uneven, MPIC will flag the mismatch and the order fails. Use a robust DNS provider and verify propagation before calling the CA.
• Internal/split-horizon DNS — if your public DNS returns different records depending on source, expect validation to fail from at least one perspective. Don't split-horizon the _acme-challenge name.

A Real-World Setup (nginx + certbot + DNS-01)

# Install
sudo apt install certbot python3-certbot-dns-cloudflare

# Cloudflare API token in ~/.cloudflare.ini (chmod 600)
dns_cloudflare_api_token = <token-with-Zone:DNS:Edit>

# Issue
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.cloudflare.ini \
  -d example.com -d '*.example.com' \
  --preferred-challenges dns-01 \
  --agree-tos --email security@example.com

# Auto-renew (certbot.timer is installed by default on most distros)
systemctl status certbot.timer

# certbot honours ARI automatically from 2.9+; renew is safe to run hourly
sudo certbot renew --deploy-hook "systemctl reload nginx"

That handles issuance and renewal. The hard part is catching the failures that don't page you — expired API tokens, rate-limits during bulk rotations, CAA drift, hijacked challenge paths, and renewals that succeed on disk but never reload the server. The "don't assume" column below covers each one.

Independent Monitoring: Why You Still Need It

Automation removes manual work. It doesn't remove failure modes — it just changes which ones occur. The cardinal sin of certificate operations is trusting the automation. Run independent monitoring, and don't assume a green renew job means a green served certificate:

Quick Reference Checklist

• Modern ACME client with ARI support (certbot 2.9+, acme.sh 3.0+, lego, cert-manager 1.13+)
• DNS-01 challenge configured with API access to your DNS provider
• Renewal job runs hourly (or via daemon mode)
• Deploy/reload hook reloads the server gracefully on renewal
• CAA record restricts issuance to your chosen CA(s)
• Independent external monitoring of every public hostname
• Renew job failures alert on the next failed run, not at expiry
• CT log monitoring for unexpected issuance on your domain

Related Articles