SSL Certificates and Subject Alternative Names

Popular browsers such as Chrome and Firefox have changed the way they verify SSL certificates, causing error messages to be displayed when users attempt to visit certain web servers. This document describes how such error messages can be safely avoided.

Background

When the X.509 standard was first published (1998), the practice was to use the Common Name field in the Subject portion of a certificate to identify the Distinguished Name of the server for which it was being issued. This led to a situation where, for each variant of a domain (www.mysite.com, www2.mysite.com, mysite.com, etc.), a new certificate had to be issued.

As X.509 evolved, the concept of a Subject Alternative Name (SAN) extension was implemented, wherein multiple elements (including email addresses, DNS names, IP addresses, and URIs) could be asserted in the Subject of a single certificate request. But since a DNS name could now appear in both the Common Name and SAN fields, which took priority?

IETF RFC 2818 (2000) describes two ways to match a domain name against a certificate:

1. Compare the domain name against entries in the Subject Alternative Name extension.
2. In the absence of a SAN extension, fall back to the Common Name.

But RFC 2818 also specifically states: "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."

Tip

Need an introduction or quick refresher? Here's a short video that provides a good overview of TLS/SSL and certificates:

RFC 6125 (2011) further affirms the precedence of the SAN:

"For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate."

The use of the Common Name field, however, was tied to an enormous number of existing certificates, and the practice remained widely popular. Even though fallback was deprecated, all web browsers continued to accept Common Names in place of missing or incomplete SAN entries.

In April 2017, Google decided to remove support for Common Name matching in certificates as part of a more general move to enhance browser security. The Google Developers' site states:

"The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. However, the commonName is ambiguous, and because of this, support for it has been a source of security bugs in Chrome, the libraries it uses, and within the TLS ecosystem at large. The compatibility risk for removing commonName is low. RFC 2818 has deprecated this for nearly two decades, and the baseline requirements (which all publicly trusted certificate authorities must abide by) has required the presence of a subjectAltName since 2012. Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48."

Regarding the Subject Alternative Name Extension, section 7.1.4.2.1 of the CA/Browser Forum Baseline Requirements states:

"This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully‐Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted."