Changes to 13-MAR-2017: Chrome disables support for mandatory features of HTTPS between r4 and r5
*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] 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, [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.
Only in r4
Only in r5 --> Modified slightly between r4 and r5