Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: allow wildcard altnames in acme-client.conf
To:
Gregory Edigarov <edigarov@qarea.com>
Cc:
tech@openbsd.org
Date:
Sat, 19 Sep 2026 13:00:20 +0100

Download raw body.

Thread
On 2026/09/18 17:56, Gregory Edigarov wrote:
> 
> On 9/18/26 17:29, Theo de Raadt wrote:
> > Stuart Henderson <stu@spacehopper.org> wrote:
> > 
> > > It would seem reasonable for acme-client to run a user script to update
> > > zones - on a pure-base install that script could write to a file which
> > > is $INCLUDE'd in a zone and reload/notify - otherwise poke at a DNS
> > > provider's API or nsupdate.
> > The privsep will get in the way.  Probably requires a good amount of
> > surgery.  But it will be worth it to have a way to perform actions,
> > maybe also for other things?

ah yes, of course.

The use-case for dns-01 will be reduced when dns-persist-01 is done (the
ACME client will not need to update DNS on-the-fly with that) so maybe
it's not worth the trouble unless there's a really good reason for other
actions. It does still seem a way off from getting through IETF though.
https://github.com/ietf-wg-acme/draft-ietf-acme-dns-persist/issues/64

> with that new 47 days certificate lifespan the way to
> automate it become a must. sorry, just my 0.005 cents

acme-client works ok even with the newer "shortlived" (160 hours)
profile needed for IP address certs.

It's just limited in what challenge types it supports, so it's fine
as long as it can provide a file reachable by http at the certificate
hostname/IP address, but can't be used to do the cert requests from a
management server for distribution to other machines that don't want to
be running externally-accessible http.