On 2026-09-17 20:31 +01, Stuart Henderson <stu@spacehopper.org> 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..
>

ah, I misremembered, indeed, the rfc only recommends validating
resolvers, it doesn't say the zone should be signed.

I guess the issue then was that we can't update zones in a sensible way?
We don't have nsupdate and nsd doesn't support dns updates either.

-- 
In my defence, I have been left unsupervised.