Summary

  • RFC 9773 lets a certification authority recommend when a client should attempt renewal and lets a new order name the certificate it is meant to replace. The client still chooses a randomized instant, maintains backoff and fallback, completes ACME and deploys the result under local control.
  • A suggested window, accepted replaces value, valid ACME order, downloaded certificate, CT entry, installed file and observed TLS handshake are different evidence. Safe automation advances only when the actor responsible for the next transition proves it.

A day became a minute

Imagine a certificate fleet receiving a generous 24-hour renewal window. The certification authority has done what a central observer can do well: move work away from a future load spike and give clients room to spread themselves out.

At the next scheduler wake-up, the renewal graph rises vertically.

Some clients rounded their chosen instant to the same cron boundary. Some could not sleep until an exact time and treated a selected instant before their next wake-up as a reason to act now. Some had lost retry state during a redeployment. Some were several minutes wrong about the current time. The CA supplied an interval; local machinery reconstructed a deadline.

This is an analytical scenario, not a report of a named incident. It exposes the question hidden inside renewal automation: who owns the clock at each stage?

The answer is not “the CA” or “the client.” Authority changes hands. The CA can recommend an interval because it sees issuer-wide demand and may know about an urgent compliance event. The client chooses when to attempt renewal because it knows its wake cycle, error history and local constraints. The ACME server decides whether an order can be issued. The subscriber decides where the result is stored, when processes reload and how failure is reversed. A live endpoint decides, through its current configuration, which certificate it presents. An observer can sample that fact, but cannot infer every unsampled edge from one successful connection.

RFC 9773 is valuable because it does not erase those distinctions. It creates a narrow coordination signal and leaves execution with the systems that bear the consequences.

The authority advertises a source of advice

An ACME server that supports Renewal Information advertises a renewalInfo URL in its directory object. A client uses an unauthenticated GET to request information for one certificate. The path does not use a database row or an operator-invented name. It combines the certificate's Authority Key Identifier key identifier with its DER-encoded serial number, base64url-encodes both and separates them with a period.

That construction gives the request a reproducible subject. It does not make the response a command.

The required suggestedWindow object contains start and end timestamps. They bound the period in which the CA recommends that renewal be attempted. An optional explanationURL can tell an operator why the interval changed—for example, because the issuer is balancing load or preparing for a mass-revocation event.

The word “suggested” carries the architecture. The interval is not the X.509 validity period. It does not amend notBefore or notAfter. It is not a CRL or OCSP answer and does not, by itself, say that the existing certificate has been revoked. It is not evidence that a client fetched the response, chose a time or began an order.

Those separations matter during an emergency. A CA may place the window wholly in the past to encourage immediate renewal. A slow client clock may still read that interval as future. A client that does not implement ARI will not see it at all. Central knowledge can sharpen a signal, but it cannot manufacture local adoption.

Randomness belongs to the client

RFC 9773 recommends choosing a uniformly random instant within the suggested window. If that instant is already past, the client attempts renewal immediately. If it can schedule itself precisely, it waits for that instant. If the selected time falls before its next ordinary wake-up, it acts now. Otherwise it waits until the next renewal-information check and evaluates again.

This is deliberately not a server-selected appointment. If the CA assigned one exact timestamp to every certificate, it would need to know whether each client can honour it, whether local maintenance rules permit it and whether a failed attempt should be retried then. A window preserves ecosystem coordination while leaving execution local.

Uniform selection also is not a magic guarantee of a smooth graph. The implementation must retain the chosen decision long enough to avoid drawing a new “random” time at every wake. Its random source and scheduling resolution must not cause a large cloned population to bunch. Its clock must be monitored. Its fleet orchestrator must not replace per-certificate choices with one global job boundary.

The standard makes one related point explicit for cron-based clients: checking more often may require storing failure information so that increased wake frequency does not defeat backoff. Useful state includes failure count for an order and the time of the most recent failure. A stateless scheduler can convert resilience into pressure by forgetting why it was supposed to wait.

A window with end equal to or earlier than start is invalid. The client treats that as though it failed to receive a usable response and follows an appropriate retry or fallback schedule. Invalid advice does not acquire authority because it came from the expected URL.

Retry-After is a polling cadence

ARI gives Retry-After a more precise role than many HTTP users expect. Here it expresses the desired time until the next RenewalInfo fetch—both a requested minimum and maximum—rather than merely the earliest instant at which a failed operation may be repeated.

The distinction is easy to lose in metrics. A client that obeys Retry-After: 21600 has accepted a six-hour information-refresh cadence. It has not scheduled the certificate order for six hours later. The selected renewal instant remains a separate local fact.

Error backoff takes priority. A temporary connection or 5xx failure should trigger bounded exponential backoff. If temporary retries are exhausted, or if the response has a long-term defect such as missing Retry-After, an invalid object, DNS failure, connection refusal or a non-5xx HTTP error, the client returns after six hours or another locally configured default.

Operators therefore need two clocks: when to ask the CA again, and when to attempt renewal. A third clock governs retries inside the ACME order. Combining them into one field called next_run makes it impossible to explain whether a delay came from issuer advice, local selection, information-fetch failure or issuance failure.

Let’s Encrypt's integration guidance recommends checking ARI for each certificate at least twice daily and keeping a remaining-lifetime fallback. That is first-party operational guidance, not a universal constant imposed by RFC 9773. A client should know which limits come from the protocol, which come from its CA and which come from its operator.

The predecessor gains a name, not a deployment receipt

ARI adds an optional replaces field to the ACME order. It carries the same certificate identifier used in the RenewalInfo request and tells the server that the new order is intended to replace a clear predecessor.

The field is useful. A CA can recognize eligible renewals, give orders in the recommended window appropriate priority or rate-limit treatment, and track whether certificates affected by an incident have a successor. The server checks account and identifier relationships according to its policy. If another non-invalid order has already marked the predecessor as replaced, the server returns HTTP 409 with alreadyReplaced.

But the relationship is an issuance relationship. An accepted replaces value does not prove that the client downloaded the successor. It does not prove that a load balancer received it, that a web server reloaded, or that the old private key left memory. Even a CA's record that a predecessor was replaced must be read within the server-side meaning specified by the protocol.

That semantic restraint is a safety feature. A CA should be able to coordinate renewal lineage without being asked to attest to subscriber infrastructure it cannot observe.

Issued is not installed

RFC 8555 still supplies the certificate-issuance machinery. The client submits a new order, satisfies identifier authorizations when required, sends a CSR to the finalize URL, watches the order move through its states and downloads the certificate from the populated certificate URL.

Each state proves something bounded.

An order in ready means the server accepts that its requirements are satisfied and awaits finalization. processing means issuance is under way. valid means the CA issued the certificate and made its URL available. A successful POST-as-GET downloads the certificate bytes.

None of those states installs the bytes on a service.

Between download and active use lie storage permissions, secret distribution, certificate-chain assembly, private-key matching, configuration validation, process reload, connection draining, edge replication and rollback. A central certificate manager may finish while an old worker continues to serve. A new file may exist beside a process that never reopened it. One region may converge while another remains on the predecessor.

The operations model should make those transitions explicit:

  1. ARI information fetched and validated.
  2. Renewal instant chosen and persisted.
  3. ACME order created with predecessor lineage.
  4. Authorization and finalization completed.
  5. New certificate downloaded and fingerprinted.
  6. Artifact distributed to named targets.
  7. Configuration checked and process reloaded.
  8. Local service presents the new fingerprint.
  9. External observations confirm the intended edges.
  10. Old material is retired after a bounded recovery window.

A single “renewed” boolean cannot represent this state machine without hiding failure.

CT sees issuance, not the serving path

Certificate Transparency adds another tempting green signal. RFC 9162 describes public logs of TLS server certificates as they are issued or observed. The logs allow monitors to audit CA activity, detect unexpected issuance and test append-only behaviour.

That is powerful evidence. It is not deployment evidence.

A certificate may be submitted to a log before a subscriber downloads it. A third party may submit a chain. A precertificate may appear as part of issuance. The log does not inspect every endpoint and does not report which load balancer currently holds the matching private key.

The correct inference is: this certificate or precertificate entered a transparency mechanism under the log's rules. The incorrect inference is: the production service has adopted it.

CT should remain in the evidence ledger because it can reveal unauthorized issuance and help reconcile the CA's output. It should not advance the deployment state on its own.

The handshake is stronger, but still sampled

TLS 1.3 provides a more direct observation. In a certificate-authenticated handshake, the server sends its certificate chain in the Certificate message, proves possession of the corresponding private key through CertificateVerify and completes the authenticated transcript with Finished.

A cache-bypassed connection to a named endpoint can therefore show which certificate that endpoint presented at that moment. Compare the leaf fingerprint, issuer, identifiers and validity with the artifact expected from the ACME order. Repeat through each relevant network path, address family, region, protocol termination layer and any SNI variation.

The evidence remains scoped. One successful connection does not prove that every anycast site, CDN edge or load-balancer member has converged. A connection through one resolver or one IPv4 address may miss a stale IPv6 path. Session resumption may avoid the full certificate exchange. An internal probe may terminate at a different layer from public traffic.

Running evidence is primary only when its observation boundary is named. “Presented by edge X over a fresh TLS 1.3 handshake at time T” is strong. “Deployed globally” is a much larger claim that requires a sampling plan capable of supporting it.

The evidence ledger

For every certificate, preserve linked but separable facts:

  • certificate identifier, CA directory and last successful RenewalInfo fetch;
  • raw window start and end, explanation URL, response fingerprint and Retry-After;
  • chosen instant, selection method, clock offset, scheduler resolution and persistence record;
  • fallback threshold, failure count, last failure and next permitted retry;
  • predecessor identifier, ACME account, order URL and replaces result;
  • authorization, finalize and valid-order timestamps;
  • downloaded certificate fingerprint, chain, key match and storage destination;
  • distribution targets, configuration checks, reload receipts and rollback state;
  • fresh handshake observations by edge, address family and termination layer;
  • predecessor retirement time and proof that recovery is no longer needed.

Do not put private keys, full account credentials or unrestricted infrastructure topology into an analytics ledger. Evidence can be minimal and still causal. Fingerprints, controlled target identifiers and signed operator records answer most questions without widening secret custody.

Each actor should report what it can actually know. The CA reports advice and issuance. The client reports selection and ACME progress. The deployer reports artifact custody and reload. The endpoint presents a certificate. The observer records a sampled handshake. No layer needs to borrow the authority of the next one.

Running code completes the sentence

The design follows a broader Internet discipline. A recommendation is not operational reality. Publication is not adoption. A coordination artifact becomes valuable when participants can implement it, validate it locally and keep later choices with the systems that run.

ARI's minimum shared layer is small: advertise the information resource, identify the certificate, express a recommended window, give a refresh cadence and convey predecessor lineage. It does not need to centralize the subscriber's deployment schedule or declare a live service changed.

Localized decision appears in the client's selected instant, backoff and fallback. Voluntary adoption appears in whether the client implements ARI at all and how it integrates the signal into its renewal machinery. Running-code primacy appears at the end: a new certificate becomes operationally relevant when deployed systems present and use it.

The CA can own the window without owning the clock. The client can own the attempt without owning issuance. The deployment system can own installation without proving every path. The observer can prove one path without declaring the fleet complete.

That is not fragmented responsibility. It is precise responsibility—the condition under which automation can become both faster and safer.

Sources