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