I had a"fun" incident recently, where a customer switched Certificate Authority for all their certificate needs. Of course, they did not choose Let's Encrypt (it's free, it can't be good), but an expensive, external IT contractor. And not a small one, either.

You would expect that one of the larger German system vendors is capable of issuing a certificate that complies with the most recent requirements for those TLS certificates. Due to the changing ITSEC landscape, browser vendors do issue new requirements and deprecate old, insecure behaviours. All with pretty long warnings and transition periods.

So my colleagues and I were rather surprised, when the browser turned on all the red lights, warnings, klaxons, ... once we deployed the certificate. It turned out, that the external service provider did not include the hostname of the server we were requesting the certificate for as a "SAN" (Subject Alternative Name).

Now, back in the 1990ties, entering the hostname of the web server into the "common name" (CN) field of the certificate was enough to make SSL work. But back in the year 2000, with the advent of TLS, Request for Comments: 2818 "HTTP over TLS" explicitly deprecated the usage of the CN field:

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.