On Thu, Sep 17, 2026 at 08:31:08PM +0100, Stuart Henderson wrote:
> On 2026/09/17 20:20, Florian Obser wrote:
> > On 2026-09-17 07:48 +10, Jonathan Matthew <jonathan@d14n.org> wrote:
> > > If you put a wildcard alternate name in acme-client.conf, you currently
> > > get a syntax error:
> > >
> > > /etc/acme-client.conf:20: syntax error
> > >
> > > which is reasonable, since this generally requires answering challenges
> > > that acme-client does not support, such as dns-01.
> > >
> > > In some circumstances, though, acme-client doesn't need to answer any
> > > challenges to get such a certificate issued.  For instance, our
> > > commercial certificate provider will issue anything under our organization's
> > > domain without any challenges, since EAB is enough proof for them.
> > >
> > > Given that, I'd like to adjust the config parser so wildcards
> > > are allowed in alternate names with the diff below.
> > >
> > > If you try to use this against an ACME server that will require a
> > > challenge, you get something like this (from pebble, in this case):
> > >
> > > acme-client: https://localhost:14000/authZ/JsLllu81TMKVxklrqHxZnccTsX2WfSyer6uigfWBUJo: bad challenge
> > >
> > > which is about as helpful as the syntax error to my mind.
> > >
> > > ok?  or do I need to wait until there's a challenge type we can
> > > support?
> > 
> > Fine by me.
> > 
> > I posted a diff for dns-01 a few years back, but that met with
> > resistance. IIRC it was requested that it should work out of the box in
> > base, but that's impossible because we do not have a dnssec signer.
> 
> dns-01 doesn't need dnssec though..
> 

My hope here is that letsencrypt will support a revised dns-persist-01 soon,
for which we'll be able to add a provisioning mode to acme-client that will
just print out the dns record for the operator to publish through whatever
process they use.  This is a one time operation so it doesn't need to be
automated.