I don't think those are quite the same thing. I had been thinking that the profile was mainly for use by modern TLS servers (as the name suggests) that don't need the CN field and didn't need the longer authorization reuse period. I don't particularly object to it also being used for the first to get shorter duration certificates, but I'm not sure it should be the general "beta test" profile.
I guess I'm just asking if this is intended to be the general direction, that changes will usually happen for "tlsserver" before "classic" (and so it is an early adopter profile in general, and I should only use it if I'm okay with that), or if it just so happens to line up that way this time but in the future "tlsserver" will be the general "modern TLS server profile" but not the more general getting-changes-first one? Or has nothing to that degree been decided yet?
It is not a "beta" profile. Any change that is being made to tlsserver is one we believe the WebPKI is ready for.
As the docs say, it makes the best choices for clients who embrace automation and want the best they can get, without being held back by legacy concerns and slower rollouts.
In that sense, early-adopter here means people who are not held back by compatibility or legacy concerns. We did debate a bit about what to put in the announcement, as I'm not sure there's a more succinct way of summarizing the audience in a short announcement.
As an aside I've noticed quite a bit of push back for dropping CN. We tried to drop this in Certify The Web v7.x products and will be reverting that in our next update, just too many people still expected it or "need" it. Likewise several CAs reject orders where the CSR doesn't include it, including google last time I checked.
Yeah, ZeroSSL / Sectigo require CN in their CSRs, which is annoying but what can ya do.
I'm this close to dropping CN support from CertMagic/Caddy entirely (I don't think we ever issued certs with CN, but this proposal is to completely ignore CN when loading certificates):
^ That's actually a bug fix btw.
I'm at the point where I'm ready to just say "Figure it out, CN in this context has been deprecated too long."
It is a bit off topic here, but what is the suggestion to display for a human on a GUI that identifies the certificate, if there is no CN?
An example as of today, vSphere/vCenter:
I have a fear that if every software out there handles correctly a certificate without CN, one day there will be a push of not having CN on a leaf certificate not optional, but obligatory (as Letsencrypt already enforcing this with the tlsserver and shortlived profiles, not allowing the users to have a choice).
Are you guys sure that this is still current? I've been developing an ACME client for a while now, and it has never supported sending a CN in its CSRs. I've been running test infrastructures with it that include both Google and ZeroSSL, and it works just fine. This is fairly fresh though, looking at the renewal history I've only been testing this since late 2025.
As I mentioned before, Synology had issues handling certificates without a CN, so they could not be properly selected in the UI. Although this problem has been fixed, the menu display still relies on the CN field. At least the user-defined comment field is still available as an alternative.
to dropping CN support from CertMagic/Caddy entirely (I don't think we ever issued certs with CN, but this proposal is to completely ignore CN when loading certificates):
