SSL Certificate with SubjectAlternativeName (SAN)

If you want to create an SSL certificate for multiple subdomains, you could either use a wildcard certificate like *.example.com or you could use an SSL certificate with SubjectAlternativeName (SAN).

For example, if you create an SSL certificate with SubjectAlternativeName (SAN) like this:

CN: gitlab.example.com
SAN: registry.example.com, mattermost.example.com

In my understanding it was one main name (gitlab.example.com) and two aliases (registry.example.com, mattermost.example.com).

But when I’ve accessed gitlab.example.com with my browser, the certificate (canonical name) was marked as invalid:

Certificate error
There are issues with the site's certificate chain
(net::ERR_CERT_COMMON_NAME_INVALID).

Explanation

As mentioned in the RFC6125 (released in 2011) the certificate validation must check for SAN (SubjectAlternativeName) first. If SAN exists, then the CN (Common Name) will be ignored:

RFC6125:

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.

Conclusion

So keep in mind, if you have an SSL certificate which uses SAN (SubjectAlternativeName) you must provide all aliases for your domain as SubjectAlternativeName, because CN (Common Name) will be ignored!

You can check your certificate content with the following openssl command:

$ openssl x509 -in example.com-cert.pem -text -noout

 Subject: CN=git.example.com

 X509v3 Subject Alternative Name:
 DNS:git.example.com, DNS:mattermost.example.com, DNS:registry.example.com

Just check if all of your desired aliases/subdomains are present in the X509v3 Subject Alternative Name section.

Note: You can easily generate your own Let’sEncrypt SSL certificate with SubjectAlternativeName (SAN) via certbot