Skip to content
Axelspire

Certificate Automation Readiness: ACME, ARI, and the 47-Day Mandate

SC-081v3 makes automation binary: either renewals run unattended or services break at scale. This page maps ACME, ARI, client support, and a maturity model to the 47-day timeline.

Certificate Automation Readiness: ACME, ARI, and the 47-Day Mandate

Section titled “Certificate Automation Readiness: ACME, ARI, and the 47-Day Mandate”

TL;DR: For 47-day public TLS you need unattended renewal, automated DCV, automated deploy, and monitoring—plus ARI (RFC 9773) on the client for CA-coordinated timing and mass-revocation resilience.

Overview

Section titled “Overview”

The CA/B Forum SC-081v3 phasedown (200 → 100 → 47 days, with shrinking DCV reuse) turns “we renew mostly on time” into an outage factory. This guide aligns with renewal automation, lifecycle management, and the ACME standard.

Related: Certbot installation, DNS-01 validation, rate limiting, automation ROI.

Problem Statement

Section titled “Problem Statement”
  • Manual DCV or deploy does not survive 8+ renewals per year per cert.
  • Static renewal thresholds miss CA-driven early renewal (revocation, incidents).
  • DNS API tokens expire; at 47-day cadence that becomes a top failure mode.
  • acme.sh without ARI cannot react cleanly to ARI “renew now” signals.
  • OV/EV still needs CA or CLM APIs—pure ACME may not cover the whole estate.

Failure scenario: Cron renews at “30 days left”; CA moves ARI window for incident response; rate limits block the batch; no replaces field—outages on high-traffic names.

ACME: foundation layer

Section titled “ACME: foundation layer”

RFC 8555 (ACME) covers account, order, challenges, issuance, revocation. If certbot/acme.sh/Lego already issue certs, the next gaps are DV method, deploy, monitoring, and ARI.

Domain validation: bottleneck

Section titled “Domain validation: bottleneck”
MethodProsCons
HTTP-01Simple on single originNo wildcards; fragile behind CDNs/LB
DNS-01Wildcards; decoupled from HTTPNeeds stable DNS API + credentials
TLS-ALPN-01TLS-only pathsLess common operationally

For 47-day + short DCV reuse (see 47-day guide), DNS-01 is often the primary choice—provided API tokens are rotated and monitored.

Critical: DNS API credentials must outlive the renewal cadence; expired API keys are a common renewal failure.

ARI: RFC 9773

Section titled “ARI: RFC 9773”

ARI adds a renewalInfo endpoint: the CA returns a suggestedWindow (start/end). Clients should renew inside the window and send replaces on the new order. Benefits:

  • Mass revocation: CA can set window in the past → clients renew immediately.
  • Rate limits: Let’s Encrypt exempts qualifying ARI renewals with replaces.
  • Load smoothing: Staggers renewals across time.

Example response shape (illustrative):

GET /renewal-info/... HTTP/1.1


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


{
  "suggestedWindow": {
    "start": "2026-04-15T00:00:00Z",
    "end": "2026-04-16T00:00:00Z"
  },
  "explanationURL": "https://letsencrypt.org/docs/ari"
}

Client support (check current versions in your environment)

Section titled “Client support (check current versions in your environment)”
  • Certbot: ARI from 4.1.0+
  • Lego: ARI supported
  • Ruby acme-client (e.g. Shopify): ARI supported
  • cert-manager: 1.15+ (enable feature gate / experimental options per release notes)
  • acme.sh: No ARI (as of common 2024–2026 tracking—verify issue tracker)
  • win-acme: ARI implementations exist

RFC 8555 vs RFC 9773: 9773 extends 8555—orders, challenges, and accounts stay the same; renewal timing and replaces are additive.

Automation maturity model

Section titled “Automation maturity model”
LevelDescriptionSC-081 survival
0 ManualPortal + SSH/RDP installFails before 47-day phase
1 Semi-automatedACME issues but manual DCV/deploy or weak monitoringFragile at 100-day
2 Fully automatedEnd-to-end unattended; static renew thresholdOK routine; weak on mass revocation
3 CA-coordinatedLevel 2 + ARI + replacesTarget for 47-day operations

Readiness checklist

Section titled “Readiness checklist”

Infrastructure audit

Section titled “Infrastructure audit”

Per public cert: FQDNs, CA, expiry, renewal path (manual / ACME / CLM), client and version, DNS provider + API auth, deploy mechanism (hooks, GitOps, cert-manager), monitoring owner.

ACME client upgrade path

Section titled “ACME client upgrade path”

Align versions with ARI requirements; plan off acme.sh if ARI is mandatory for your risk model.

DNS provider API

Section titled “DNS provider API”

Prove TXT create/delete; credential expiry and ownership (not tied to one human’s account).

Deployment pipeline testing

Section titled “Deployment pipeline testing”

Quarterly forced renewal: order → DCV → install → reload → monitor green.

Monitoring

Section titled “Monitoring”

External expiry checks; alert ~80% of lifetime (at 47 days ≈ ~37 days remaining ≈ ~10 days to react). Watch ACME logs for silent retries.

Enterprise CLM vs ACME-only

Section titled “Enterprise CLM vs ACME-only”

OV/EV, code signing, and S/MIME often need DigiCert, Sectigo, Keyfactor, Venafi, etc.—see vendor comparison. For DV at scale, ACME + ARI + DNS-01 is usually the cost-effective core.

Section titled “Related documentation”