On 2025/12/14 20:53, Lloyd wrote:
> > 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.

oops yes, copied to the email, tried it, fixed it, didn't update the
email. it does need shortlived.

> For an IP-only cert, I have used "domain 1.2.3.4 {" syntax for clarity.

that is indeed more clear, but if it has to be done like this it doesn't
make the parser look very intelligent:

domain 192.0.2.0 {
    domain name ip:192.0.2.0
    ....
}

> > 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.

nobody _can_ use the CN as generated by acme-client other than the CA
because it's simply not available anywhere else. we know that it makes
no difference for letsencrypt. buypass are no longer issuing so I can't
check that. afaik we don't do EAB so zerossl doesn't work. step-ca uses
templates and can be made to copy CN from the CSR but I think that's not
a standard use-case

"subject": {"commonName": {{ toJson .Insecure.CR.Subject.CommonName }}}

so I don't think there's a need for a config knob here.