13-MAR-2017: Chrome disables support for mandatory features of HTTPS
Because mandatory features of the RFC are optional
A coworker of mine uses Chrome canary, probably because he likes to use broken software, and noticed that some of our internal web pages were reporting an issue with certificate validation. He looked into and found a Chromium Bug Report where support for matching the hostname from the URL against the X.509v3 certificate's subject distinguished name's common name attribute has been disabled by default for new builds of Chromium.
The bug report, CrBug 700354, specifically mentions RFC 2818 (HTTP over TLS, or HTTPS) in it.
This change is intentional and its purpose is simply to not support this deprecated feature. It currently possible to re-enable this functionality in some cases, but support for that will be dropped entirely in Chromium 65.
RFC 2818 specifically says this functionality is mandatory. While operators should not create certificates this way because it is deprecated, HTTPS clients MUST support this or they are not compliant with RFC 2818. That is, creating certificates this way is deprecated -- HTTPS clients MUST still support it.
The relevant wording from Section 3.1 (Server Identity) follows:
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.Given this wording, and the specific meaning of MUST supplied in RFC 2119 (referenced as a normative document for the definition of MUST in RFC 2818) as "an absolute requirement of the specification" it is apparent that the Chromium team is moving away from supporting a standards-based approach to HTTPS.
A brave new web indeed.
Hooray.