Index | Thread | Search

From:
Peter Hessler <phessler@theapt.org>
Subject:
Re: acme-client(1): add support for let's encrypt iPAddress certificates
To:
Lloyd <ng2d68@proton.me>
Cc:
Stuart Henderson <stu@spacehopper.org>, "tech@openbsd.org" <tech@openbsd.org>
Date:
Thu, 11 Dec 2025 22:31:57 +0100

Download raw body.

Thread
On 2025 Sep 18 (Thu) at 18:59:33 +0000 (+0000), Lloyd wrote:
:Stuart Henderson wrote:
:
:> We can still work on it in the meantime, but this is a big enough change
:> that it should wait until after release for commit - if there is any
:> problem we want to be able to find it before some users are stuck with
:> it for 6 months.
:
:I agree - it's also prudent to wait on account of Let's Encrypt doesn't
:support this in production just yet, and their flagship tool (certbot)
:doesn't even support it IIRC. I'd prefer for the dust to settle first.
: 
:> Config files and the manual will be simpler if the parser is changed to
:> allow using ip:XXX directly here, i.e. "domain ip:192.0.2.0", without
:> needing to specify "domain name". Then we could also bring in the ip:
:> text
:> here,
:
:This was intentional. The handle should be a static identifier. I felt
:that whether or not "ip:" gets stripped from the handle becomes
:ambiguous. Which is the real handle - with or without "ip:"? Which do
:you specify on the command line? The handle gets screened as a valid
:domain name so cannot contain colons - but that needs to be supported
:for IPv6 but still prevent you from entering something invalid like
:www:openbsd:org. I thought it would make the parser unnecessarily
:complex.
:
:Thanks for all the feedback on the manual page, I had intended to go
:back and clean that up later, wanted to get this out there and get some
:eyeballs on the code in the meantime while the CAs are testing this.
:
:> I don't think any current CAs supported by acme-client are requiring
:> this? I'm thinking the only thing that might require CN is software
:> using the cert which might (though shouldn't) get confused if it's not
:> there.
:
:I left this as an on/off knob for legacy support. Maybe someone out
:there prefers CN's in their certs and they are still supported for the
:default long-lived profiles.
:
:Regards
:Lloyd
:

I was looking at this topic and noticed thet LetsEncrypt is planning on
releasing this to production soon, so IMHO this is a good time to clean
up the diffs and get it in.

Can you update the patches and re-send?


-- 
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.