From: Stuart Henderson Subject: Re: acme-client(1): add support for let's encrypt iPAddress certificates To: Janne Johansson Cc: Lloyd , Peter Hessler , "tech@openbsd.org" Date: Thu, 18 Dec 2025 11:56:48 +0000 On 2025/12/18 08:28, Janne Johansson wrote: > > One other thought, I intermittently ran into this whilst testing: > > > > acme-client: https://acme-staging-v02.api.letsencrypt.org/acme/authz/foo/bar: bad HTTP: 503 > > acme-client: transfer buffer: [{"type": "urn:ietf:params:acme:error:rateLimited", "detail": "Service busy; retry later."}] (90 bytes) > > acme-client: bad exit: netproc(58848): 1 > > > > This was not due to any abuse or explicit rate-limiting; rather, it was > > random, likely overload on their end. It got me thinking acme-client will > > return 1 on any error. However a 503 could be interpreted as "try again > > later". A once-daily cron job to update certificates would simply fail > > due to an overload. If we were able to return more granular error values > > to the caller, a decision could be made to say, retry in a few minutes > > rather than abort (as opposed to a more serious error like a 403). > > Then again, if LE is getting hammered with requests, then having all > of the worlds clients come back within minutes is probably not going > to help a lot either. This particular one seems rare enough not to have to worry about it too much, especially in prod. But retry schedules are a thing that are more sensitive with short-lived certificates. Also letsencrypt's acme servers signal the recommended retry time in many cases (Retry-After). To do a really good job of this, clients probably could do with keeping state. Although if Retry-After is not too far in the future, waiting and retrying rather than exiting might make sense.