From: Lloyd <ng2d68@proton.me>
Subject: Re: acme-client(1): add support for let's encrypt iPAddress certificates
To: Stuart Henderson <stu@spacehopper.org>
Cc: Peter Hessler <phessler@theapt.org>, "tech@openbsd.org" <tech@openbsd.org>
Date: Sun, 14 Dec 2025 21:07:47 +0000

Stuart Henderson wrote:

> 
> Diff below merges this to -current. Works for me with a shortlived IP
> address cert on letsencrypt staging, with a standard cert on letsencrypt
> prod, and src/regress/usr.sbin/acme-client (using pebble) is still
> happy.
> 
> I have fixed "new sentence new line" in the manpage changes but not
> made any substantial changes including any of the things I suggested;
> comments on those bits:

Thanks for cleaning this up, Stuart. An early Christmas gift for sure as
it sounds like LE will enable this in the coming week or thereabouts.

> but as things stand it's pretty ugly for an ip-only cert
> 
> domain ip_only_cert {
> domain name ip:192.0.2.0
> alternative names { ip:2001:db8:0:1::1234 }
> domain key "/etc/ssl/private/iponly.key"
> domain chain certificate "/etc/ssl/iponly.pem"
> sign with letsencrypt-staging
> profile tlsserver
> }

FWIW I believe this example would need to use the 'shortlived' profile.

> AFAIK the CA will generate CN themselves rather than copying from the
> CSR. Certainly letsencrypt does (with the default profile).
> 
> Since the CSR is not stored, I think the only reason for having a knob
> would be if a CA fails to issue a cert if there's no CN (letsencrypt
> staging, prod, and pebble work) so I think I'd prefer to drop the knob
> unless/until it's proven that we need it. Simplifies the docs too.

I don't hold any particularly strong opinions on this so defer to your
better judgement. I don't use the CN myself, but someone else might.

Regards
Lloyd