Changes to 13-MAR-2017: Chrome disables support for mandatory features of HTTPS between r5 and r6
'''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 [https://bugs.chromium.org/p/chromium/issues/detail?id=700354 | Google 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.
(blank line)
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 [https://bugs.chromium.org/p/chromium/issues/detail?id=700354 | 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.
(blank line)
The bug report, [https://bugs.chromium.org/p/chromium/issues/detail?id=700354 | CrBug 700354], specifically mentions [https://tools.ietf.org/rfc/rfc2818.txt | RFC 2818] (HTTP over TLS, or HTTPS) in it.
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.
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.
(blank line)
Given this wording, and the specific meaning of '''MUST''' supplied in [https://tools.ietf.org/rfc/rfc2119.txt | 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.
(blank line)
A brave new web indeed.
(blank line)
Hooray.
Only in r5
Only in r6 --> Modified slightly between r5 and r6