Changes to 13-MAR-2017: Chrome disables support for mandatory features of HTTPS between r1 and r8
**Because mandatory features of the RFC are optional** --> '''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]
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.
(blank line)
This change is intentional and its purpose is simply [https://codereview.chromium.org/2719273002/ | 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.
(blank line)
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.
(blank line)
The relevant wording from Section 3.1 (Server Identity) follows:
(blank line)
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 r1
Only in r8 --> Modified slightly between r1 and r8