We often get questions from users about TLS handshake failures that are caused by misconfigured TLS certificates. The server and client drivers use the hostname verification algorithm described in RFC2818 Section 3.1, specifically this text:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

Users often create TLS certificates that have a SAN dNSName of something like "foo.example.com", and a CN of something like "foobar.example.com". They try to connect to foobar.example.com and the TLS handshake fails, leading to a lot of confusion.

TLS is complicated and difficult to explain. Let's try to give the users a fighting chance in this case.