From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: acme-client(1): add support for let's encrypt iPAddress certificates
To: Lloyd <ng2d68@proton.me>
Cc: "tech@openbsd.org" <tech@openbsd.org>
Date: Sun, 31 Aug 2025 11:00:03 +0100

On 2025/08/31 05:16, Lloyd wrote:
> Any feedback on this LE patch from July or was anyone able to test further?
> 
> I nearly forgot I submitted this. There is some discussion to be had on
> the internal handling of SANs in acme-client(1) now that both IP addresses
> and host names are supported as valid Subject Alternative Names with LE.
> 
> Regards
> Lloyd
> 
> > Hi all,
> > 
> > I extended the ACME profile patch posted by sthen@ a few months ago to hack
> > together basic working support for Let's Encrypt IP address certificates.
> > 
> > Some notes and limitations:
> > 
> > * To issue an IP address cert, you must select the 'shortlived' profile.
> > 
> > * Their new profiles disallow the X.509 Common Name field. The "no cn"
> > directive has been added to acme-client.conf(5) to support this.

https://www.rfc-editor.org/rfc/rfc6125#section-6.4.4 is pretty old now,
I think it would be sane to not include the CN any more anyway. Either
remove outright (probably soon after an openbsd release rather than at
the current point in the release cycle) or use a default-off knob.

> > * IP certs must use an identity type of iPAddress in the SAN field in the CSR.
> > Unfortunately, acme-client(1) makes a lot of assumptions that we will only
> > ever use SAN type DNS and this is hard coded in a few places. There is some
> > internal ugliness where it packs all the altnames into an array of strings
> > and assumes they are all dns hostnames. Ideally these become structs where
> > each SAN identifier can have an idtype associated with it.
> > 
> > * The 'identifiertype ip' directive will assume all domain/altnames are of type
> > iPAddress. This works fine for a single IP or multiple of the same, but will
> > not allow you to mix and match SAN types in the same request. It's unclear,
> > but it appears Let's Encrypt would allow both types in the same CSR. Maybe.
> > 
> > * There is no good way to fix this without breaking the "alternative names"
> > syntax in acme-client.conf, because in this brave new [pki] world this is no
> > longer a simple list of strings, each string needs a type associated with it.
> > 
> > * One option could be using a different directive for IP altnames, but
> > acme-client assumes the "domain" name is altname[0]. Regex parsing is likely
> > too complex. Maybe prefixing every string with "ip:" including the domain?
> > Something to figure out but the altnames parsing scheme needs to be reworked.

Tagging with ip: in the string and working from there seems a reasonable
way to handle this to me. Then no need for extra config keywords other
than relating to the profile. I don't think this would be too ugly:

domain somename {
	domain name "ip:192.0.2.0"
	alternative names { somename.example }
	domain key "/etc/ssl/private/server.key"
	domain chain certificate "/etc/ssl/server.crt"
	challengedir "/var/www/letsencrypt/.well-known/acme-challenge"
	sign with letsencrypt
	profile shortlived
}