ACME Renewal Information: the monitoring blind spot

On July 20, 2026, the Hellenic Academic and Research Institutions Certification Authority, HARICA, told a batch of subscribers their certificates needed to be replaced. Five days later, on July 25, it recalled a larger batch from the same window. Neither certificate had expired. The problem was narrower and stranger: HARICA had quietly removed a required extension from certificates issued between March 27 and July 20, then had to walk it back to stay compliant with its own policy.

The detail worth noticing is not the recall itself. It is what HARICA used to fix it: it enabled ACME Renewal Information, ARI, so affected clients could pick up the change and replace their certificates automatically, without anyone reading an advisory or waiting for the old certificate to approach its printed expiry date.

What ARI actually is

ARI is an ACME protocol extension, standardized in September 2025 as RFC 9773, that gives a certificate authority a way to tell a client to renew earlier than the certificate's own notAfter date suggests. Instead of a client deciding purely from the expiry timestamp baked into the certificate, it can query the CA for a suggested renewal window and act on that instead.

The two problems it was built for, in the CA's own words:

• Mass revocation events: when a CA has to invalidate a large batch of certificates for a validation error or policy violation, ARI lets affected clients renew proactively instead of waiting to find out the hard way.
• Load spreading: when a large number of clients would otherwise all renew in the same narrow window, ARI can stagger the suggested renewal times to avoid a traffic spike at the CA.

Why this exists at all

The motivating example Let's Encrypt itself cites is from January 2022, when it had to revoke roughly two million certificates after discovering a validation bug: a bug in how it checked domain ownership meant some certificates should never have been issued in the first place. At the time, the only real notice mechanism was email and a compressed renewal window, which is exactly the blunt, all-at-once process ARI exists to replace.

HARICA's 2026 recalls are the same shape of event with ARI actually available this time. The affected certificates were missing an AIA OCSP URI, an access-method extension required by policy, because HARICA had removed it in a late-March change without updating the corresponding documentation. Once the mismatch surfaced, the fix was not a mass-email campaign. It was flipping on ARI and letting compliant clients pick up the shortened renewal window on their own.

Almost none of the coverage is written for monitoring

Every source that explains ARI, the RFC itself, Let's Encrypt's own posts, and the CA-tooling guides that followed, writes for the same audience: whoever configures the ACME client. That is the correct audience for implementing ARI. It is not the only audience who should care about it.

A live example of that gap: Shopify's engineering team documented moving from static renewal thresholds to ARI-based renewal timing, integrating ARI support directly into their Ruby ACME client. That is a genuinely useful case study, and it is still framed entirely from the client-implementer's side: how to consume the signal, not how to watch for it externally.

An external SSL check that only reads a certificate's own notAfter field has no way to see any of this. It correctly reports "not expired yet" for a certificate the issuing CA has already flagged for early replacement, exactly the gap that made the HARICA recall newsworthy in the first place: the certificates were valid by their own printed dates, and still wrong.

What a monitor watching ARI would actually show

The renewal-information endpoint a client queries returns a suggested window, not just a boolean. In principle, an external check could poll the same endpoint the ACME client uses and treat a CA-suggested early-renewal window as its own signal, distinct from and earlier than the certificate's printed expiry. That would surface exactly the situation HARICA's subscribers were in: a certificate that looks fine by date, flagged by its own issuer as due for early replacement.

This is not a shipped capability today. WebPixie's SSL monitoring currently validates the certificate a site actually serves against the chain, expiry, and TLS configuration, the same checks that catch a renewal that silently failed. Reading ARI as a second, earlier signal is a natural extension of that same daily revalidation, and worth watching as ARI support spreads across more CAs and clients.

The gap this leaves for now

Until a monitor reads ARI directly, the fallback is what it has always been: a shorter check interval and full chain revalidation catch a certificate that is actually broken faster than one that is merely flagged for early renewal. ARI's real value is advance notice before anything breaks, which nothing outside the ACME client itself currently surfaces. HARICA had it. Most domains, and most of the monitoring watching them, do not yet.