←back to thread

315 points Bogdanp | 5 comments | | HN request time: 1.906s | source
1. OptionOfT ◴[] No.44379914[source]
Interesting, there is no subject in the example cert shown.

Is this because the certificate was requested for the IP, and other DNS entries were part of the SAN?

replies(1): >>44380101 #
2. jaas ◴[] No.44380101[source]
We (Let's Encrypt) are getting rid of subject common names and moving to just using subject alternative names.

This change has been made in short-lived (6 day) certificate profiles. It has not been made for the "classic" profile (90 day).

replies(1): >>44382802 #
3. tialaramex ◴[] No.44382802[source]
Have you found much trouble with clients that can't cope without CN? Is this one of those situations where anything that can't cope is also hopeless for other reasons (e.g. can't speak TLS 1.2, doesn't understand IPv6, that sort of thing) and so you can tell people you're not their biggest problem ?
replies(1): >>44385626 #
4. jcgl ◴[] No.44385626{3}[source]
It’d surely be something like that. CN has been deprecated and SAN support has been required for 25 years at this point[0].

[0] https://datatracker.ietf.org/doc/html/rfc2818#section-3.1

replies(1): >>44388166 #
5. tialaramex ◴[] No.44388166{4}[source]
I'm aware that PKIX deprecated use of CN for this purpose at the turn of the century, but when browsers began ignoring CN about a decade ago (which is the first half of the adoption curve) I know Google had to ship an enterprise override for people whose corporate systems could not cope. If it's true that all or almost all systems now work properly that's great news.