UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3057.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Generate or obtain a certificate from a trusted authority that contains a SAN without a DNSName entry, e.g. a rfc822Name, but with a valid CN in the subject.
2. Apply this certificate to a web server
3. Attempt to connect to the web server

What is the expected behavior?
The connection should be accepted and shown as secure.

What went wrong?
An error page was displayed containing:

Your connection is not private

Attackers might be trying to steal your information from myhostname (for example, passwords, messages or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID

The security overview shows:

Subject Alternative Name Missing
The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.

Did this work before? Yes 57.0.2987.133 

Chrome version: 59.0.3057.0  Channel: canary
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

I have seen that there are various other reports of this all closed as working as expected and quoting RFC 2818.
However, the relevant section in the RFC is:

   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.

That sentence starts with an "If".
It is still perfectly acceptable for a certificate to contain a SAN that does not include a DNSName entry and therefore the second MUST should be followed and the CN entry used.
RFC 3280 does not mandate the presence of a dNSName.