An SSL certificate has a field called Subject. The Subject field contains the domain name that the certificate is valid for. Subject can only contain one domain name:
The field Subject can have more information, like the screenshot below, but still only one domain name:
An SSL certificate can also contain an optional field called Subject Alternative Names, or – as it is more often called – a SAN field. The SAN field contains one or multiple domain names that the certificate is valid for.
Note that in this example I only have one single SAN name. You can have many domain names in the SAN field of a certificate.
A common misconception around this is that a certificate with both Subject and SAN is valid for all domain names that are present in both of these fields. But if an SSL certificate has a SAN field, then SSL clients are in fact supposed to ignore the Subject field and look only in the SAN field for a domain name match.
This behavior is clearly specified in the RFC for HTTP Over TLS:
“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.”
In other words: If SAN exists, use only that. If no SAN exists, use Subject.
To see this behavior in action, see my short video below [52 sec], in which I use the certificate from the screenshots above on two different websites: san.tomdemo.se and subject.tomdemo.se. Can you predict what will happen?
[the video has no audio]
Since the Subject field is not used when using SAN, it can be set to anything, it could in fact be empty.
Perhaps a new best practice would be to set the Subject to something that would avoid the risk of this confusion whenever a SAN is used, like this certificate: