ARI recommendation may cause renewal outside Suggested Window

jvanasco · March 17, 2025, 8:58pm

I just dug into Boulder's source, and... ugh.

I am assuming that most Subscribers will be using Cron to schedule something daily like Certbot , which will do it's own task management and dispatch.

The current Boulder Source requires the renewal to happen within a computed window to bypass rate limits, which is generated by the same logic that powers the renewalInfo endpoint. The logic creates a buffered window around the 2/3 lifespan for 90day certs and 1/2 for shortlived. That code is here:

github.com/letsencrypt/boulder

core/objects.go

main


      
          // RenewalInfoSimple constructs a `RenewalInfo` object and suggested window
          // using a very simple renewal calculation: calculate a point 2/3rds of the way
          // through the validity period (or halfway through, for short-lived certs), then
          // give a 2%-of-validity wide window around that. Both the `issued` and
          // `expires` timestamps are expected to be UTC.
          func RenewalInfoSimple(issued time.Time, expires time.Time) RenewalInfo {
          	validity := expires.Add(time.Second).Sub(issued)
          	renewalOffset := validity / time.Duration(3)
          	if validity < 10*24*time.Hour {
          		renewalOffset = validity / time.Duration(2)
          	}
          	idealRenewal := expires.Add(-renewalOffset)
          	margin := validity / time.Duration(100)
          	return RenewalInfo{
          		SuggestedWindow: SuggestedWindow{
          			Start: idealRenewal.Add(-1 * margin).Truncate(time.Second),
          			End:   idealRenewal.Add(margin).Truncate(time.Second),
          		},
          	}
          }

Based on the above, the "optimal" is the "suggested".

My current thoughts are this:

clients should probably archive the initial renewalInfo and immediately renew at the start of the suggestedWindow if it ever changes. either boulder updated logic, or there was some issue. The margins are small though, so if there is a change you need to maximize the response time in case there is an error and a retry is needed.
renewing within a 90day cert's suggestedWindow shouldn't be too hard. It's roughly +- 1 day from the 2/3 point. this should get picked up on a daily run.
renewing a short lived cert will be hard. there is a +- 2h24m window from the halfway point to renew.

IMHO the renewal windows should be wider. I think giving a full +- 24h for 90day certs would be more useful; and at least +-12h for shorter certificates. To meet the current windows, short-lived clients will have to be running non-stop. A 90day cert will have 1-2 opportunities to renew during the current window if the client only runs daily; but a 10 day cert will require a renewal program to run at least every 4 hours. Clients will absolutely need to run hourly to see if ARI checks are needed.

Topic		Replies	Views
Can ARI-conforming clients be granted exemptions to relevant rate limits? Client dev	47	2495	May 11, 2023
What are you doing with ARI Retry-After? Client dev	28	262	March 6, 2025
API to get suggested renewal time Feature Requests	16	1148	July 29, 2018
Client Burden of Preemptive ARI Timing Selection Client dev	19	327	June 29, 2025
Documentation of Renewals Help	1	822	December 14, 2015

ARI recommendation may cause renewal outside Suggested Window

Related topics