证书 CommonName 和 subjectAltName 的关系

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.  When matching
DNS names against dNSName or Common Name fields, matching is case-
insensitive.  Also, a "*" wildcard character MAY be used as the left-
most name component in the certificate or identity in the APD.  For
example, *.example.com in the APD would match certificates for
a.example.com, foo.example.com, *.example.com, etc., but would not
match example.com.  Similarly, a certificate for *.example.com would
be valid for APD identities of a.example.com, foo.example.com,
*.example.com, etc., but not example.com.

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.

Link to "Intent to Deprecate" thread
No deprecate thread; it's been deprecated since HTTPS was first introduced (RFC 2818) in 2000.

Summary
Certificates have two ways to express the domain/IP they're bound to - one which is unstructured and ambiguous (commonName), and one which is well-defined (subjectAltName). In the absence of any subjectAltNames, Chrome currently falls back to comparing the domain against the commonName, if present.

This proposal is to remove that fallback path; in effect, requiring a subjectAltName. Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates.

Motivation
Since 1997 (X.509v3's ratification), certificates have had two ways to express a binding to a domain name - either via the commonName attribute within the certificate's subject, or via the explicitly typed (dNSName or iPAddress) of the SubjectAlternativeName Extension.

Since RFC 2818 (published in 2000, first drafted in January 1998), the use of the commonName field has been considered deprecated, because it's ambiguous and untyped - that is, it might contain a human-readable name or it might be a domain name.

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. commonName, however, is ambiguous, and because of this, support for the commonName has been a source of security bugs - in both Chrome and the libraries it uses and within the TLS ecosystem at large.

Compatibility Risk
Low. RFC 2818 has deprecated this for nearly two decades, and the Baseline Requirements (which all publicly trusted CAs must abide by) has required the presence of a subjectAltName since 2012.

Mozilla Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 ).

Usage information
From a metrics perspective, less than .002% of publicly trusted certificate validations would require this behaviour (Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).

As 1.57% of privately-trusted CA certificates rely on this behaviour (or 0.1% of all certificate validations), it may be premature to deprecate it for privately-trusted CAs; alternatively, we could remove it with an enterprise policy to allow it for a limited number of releases. Unfortunately, despite being deprecated for nearly 20 years, it's unlikely we'd be able to drive this number down (and improve the security of the ecosystem) without taking further action.

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=308330

Entry on the feature dashboard
https://www.chromestatus.com/feature/4981025180483584 (Apologies if I botched this; not sure how to capture "The standard says this is deprecated, and Mozilla supports deprecating")