From: Lloyd Subject: Re: acme-client(1): add support for let's encrypt iPAddress certificates To: Stuart Henderson Cc: Peter Hessler , "tech@openbsd.org" Date: Wed, 17 Dec 2025 19:20:46 +0000 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). Regards Lloyd Stuart Henderson wrote: > > Diff below merges this to -current. Works for me with a shortlived IP > > address cert on letsencrypt staging, with a standard cert on letsencrypt > > prod, and src/regress/usr.sbin/acme-client (using pebble) is still > > happy. > > > this is now live in prod on letsencrypt, but beware if testing, there > is a bug. > > if you list IPv6 addresses, it hits "domain list changed, forcing > renewal" on every renewal. > > this is because, when setting up found_altnames, it's doing a memcmp() > between the expanded v6 address and the compressed one, i.e. > > memcmp("xxxx:xxxx:0001:0101:0000:0000:0000:0002", "xxxx:xxxx:1:101::2", 39 > > updated diff below uses inet_ntop, rather than hand-rolled functions, > to generate strings from the addresses in an existing cert. > I also dropped the "with cn" option and setting Subject in the CSR. > > (I think v6 addresses probably ought to be normalised to the inet_ntop > form when read from the config file too - I haven't done that in this > diff. Looks like letsencrypt won't issue a cert if you try to use the > expanded form anyway). >