ACME, ARI, and Surviving 47-Day Certificates

Public TLS certificates are capped at 200 days today, drop to 100 days on 15 March 2027, and to 47 days on 15 March 2029. The only sustainable answer is ACME-based automation: issue and renew via RFC 8555, take renewal timing from the CA using ACME Renewal Information (ARI, RFC 9773), and monitor independently of the renewal process itself. This guide covers all three.

The Shrinking Certificate Lifespan

Under CA/Browser Forum Ballot SC-081v3, the maximum public TLS certificate lifetime is collapsing on a fixed schedule. The first step is already behind us — 200 days has been the cap since 15 March 2026:

The number that actually bites: DCV reuse

Maximum validity gets the headlines, but the domain-control-validation reuse period is the one that changes your architecture. It is how long a CA may reuse a successful domain validation before making you prove control again:

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) lets the CA tell your client when to renew, instead of your client guessing. Standardised as RFC 9773 (Proposed Standard, June 2025), it is the most important addition to ACME 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 certs, but it breaks down for short-lived certs and especially for emergency mass-revocation events, where a CA needs thousands of subscribers to rotate early and has no way to say so.

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 — and note that ARI stops being a nice-to-have the moment your CA starts shortening lifetimes underneath you, which Let's Encrypt is now doing on a published schedule.

Let's Encrypt Is Moving Faster Than the CA/B Forum

If you use Let's Encrypt, the Baseline Requirements are not your binding constraint — Let's Encrypt's own roadmap is stricter and arrives sooner. Announced 2 December 2025:

MPIC: What Changed in Validation

Multi-Perspective Issuance Corroboration (MPIC) means the CA repeats your domain-control and CAA checks from several geographically separate network vantage points and refuses to issue unless enough of them agree. It exists to defeat BGP hijacks and localised DNS spoofing, which could previously fool a CA validating from one location.

It phased in under Ballot SC-067, and the phases matter because "MPIC is required" has meant different things at different times:

So as of today the binding rule is three remote perspectives with enforcement, moving to five in December 2026. The quorum table in Baseline Requirements §3.2.2.9 sets how many non-corroborations are tolerated for a given number of perspectives; in practice CAs run a primary plus five remotes and need a clear majority to agree.

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