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.

Why the Lifetime Cuts Happened

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

• Revocation doesn't work. Browsers stopped honouring OCSP and CRLs years ago because they break load-time UX. The only reliable revocation mechanism is "wait for the cert to expire." If certs expire faster, the revocation window shrinks.
• Key compromise has a shorter blast radius. A stolen private key in 2025 was useful for up to a year. In 2029 it's useful for 47 days.
• Automation is now mature. ACME has been a proven, IETF-standardised protocol (RFC 8555) since 2019. The infrastructure exists to renew daily if needed.

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, in one paragraph

Your client creates an account key, asks the CA for an order covering one or more hostnames, the CA returns authorizations with challenges, you prove control by serving an HTTP file or publishing a DNS record, the CA validates, you submit a CSR, you receive the issued certificate. Modern clients do all of this in one shell command and a cron entry.

Picking a client

HTTP-01 vs DNS-01: Pick One

HTTP-01

The CA gives you a token; you serve it at http://yourhost/.well-known/acme-challenge/<token>. Easiest possible setup. Won't work for wildcards (*.example.com) and won't work for hosts behind a private network.

DNS-01

The CA gives you a token; you publish a TXT record under _acme-challenge. Works for wildcards, works for hosts that aren't publicly reachable, but requires programmatic access to your DNS. Use a DNS provider with API support (Cloudflare, Route53, DigitalOcean, deSEC, etc.) and the matching client plugin.

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"

Things that will break automation (and how to catch them)

• API token expired or revoked. The renew job logs the failure but your monitoring sees nothing until the cert expires. Watch the renew job exit code.
• DNS provider rate-limited you. Particularly during bulk-rotation events. Stagger your renewals.
• CAA record changed and no longer lists your CA. Audit changes to CAA.
• HTTP-01 challenge path hijacked by a new app on the same host. Verify your reverse proxy still serves /.well-known/acme-challenge/ to the ACME client.
• The renewal succeeded but the reload hook didn't run. The most common silent failure. Monitor served-cert expiry, not just file-system expiry.

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. Always run independent monitoring that:

• Hits your host over TCP and reads the actual served certificate.
• Alerts at 14, 7, 3, and 1 days before expiry.
• Covers every public hostname — including the ones nobody documented.
• Watches Certificate Transparency logs for unexpected issuance.
• Tests the full chain, not just the leaf.

Quick Reference Checklist

Related Articles