For quite a while, it has been common that the CN of a web server certificate also needs to be present in the SAN list, and new versions of browsers enforce this. So, if my CN is www.example.com, and the SAN has only example.com, browsers will refuse to connect, resp. show certificate warnings and have the user take extra steps (just like with expired certificates etc.).

What's the reason for this, and specifically, does it have any security advantages? After all, including or omitting www.example.com in/from the SAN doesn't make the certificate any harder to get.

  • While "just check the SAN list" may be a bit easier to implement than "check the SAN, and fall back to CN if the host name isn't found", it doesn't make much of a difference, and browsers have been doing that for years anyway.
  • In cases of shared hosters that have many domains on the same host, I could imagine a certificate having a CN of shared-host-5238.example-hoster.com and a SAN of www.example.com; a browser wouldn't connect to shared-host-5238 because that isn't included in the SAN. But that protects the server more than the client (the client would actively need to seek out the shared-host URL), and you could send requests to the shared-host URL anyway, ignoring certificate errors, so there's not much protection for the host either.
  • Is it to open up the possibility of having the CN not include the domain name at all, to free it up for organization name/location/whatever? There seems little point in this because certificates have other fields for that.

So, what is a scenario where requiring the CN being duplicated in the SAN improves security?

  • The hostnames that will be used to connect to the server must be present in the certificate as SANs. It is not an issue of duplication, it's that use of the CN field in X.509 has been deprecated in HTTPS for the purpose of storing hostname(s), and has been for 20 years now. There's nothing interesting about the CN field. Oct 27, 2021 at 13:40

1 Answer 1


... the CN of a web server certificate also needs to be present in the SAN list

No, it does not need to be present also in SAN. It needs to be present in SAN, the CN does not matter. Using the CN for the domain is deprecated for a long time and at least Chrome and similar (like Edge) enforce this for a while now.

Today it is pretty common that a certificate includes multiple domains and CN is not sufficient here. Contrary to CN the SAN also provides a clear distinction between DNS names and IP addresses.

Specifying to check only the SAN makes it obviously simpler and more clear how certificate validation should be done, compared to having rules in which cases the CN should be used and which semantics are supported (i.e. IP vs. DNS name). Simpler specification allows for simpler, more consistent, easier to understand and easier to verify implementation - which is definitely a bonus in terms of security.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .