I'm pretty sure this is because Chrome no longer falls back to matching the common name in certificates, not due to case insensitivity in matching. See  Issue 700595 .

Please attach a chrome://net-export log as per https://www.chromium.org/for-testers/providing-network-details

Based on the certificate currently being served by this server is for thenetworksolution.it - that is, it has nothing to do with the common name. Indeed, I can find no publicly trusted certificate with a common-name matching the case specified.

Note that the certificate for this website is currently being provided by Let's Encrypt, but the server has been misconfigured to send the incorrect certificate chain. Are you using a ACME client? If so, which one, so that a bug can be reported to the developers?

The server in question supports SNI, and visitors not presenting SNI will get a Let's Encrypt certificate for thenetworksolution.it instead of the cert that OP is concerned with for fe.thenetworksolution.it (signed with private root "CA Agenzia").

That said, examination of the FE cert matches dominickn's assertion; there is a CN but no SAN which matches the error mode of NET::ERR_CERT_COMMON_NAME_INVALID.

Deleted: certchain.txt 3.8 KB

certchain.txt 3.8 KB View Download

Thanks. Marking this as WontFix - it is correct that Chrome does not support matching against the commonName and requires a subjectAltName be present. See https://www.chromestatus.com/feature/4981025180483584 

Supporting matching against the commonName is a security risk, as they bypass nameConstraints.

Thank you for the detailed explanation. This CA emits certificates for internal use only. What kind of security risks we face without subjectAltName? May you point me to some sources so I might report the issue?

You can see https://nameconstraints.bettertls.com/ for a variety of test cases.

The short answer is that RFC 5280 does not apply nameConstraints (such as iPAddress or dNSName name constraints) to common names. Worse, it's not easily determined from the common name form the 'intent' (that is, if a certificate is for "eBags.com" in the common name, is it the name of the company with a dot-com in their name or for the domain eBags.com?).

If software supports matching against the commonName (whether or not subjectAltNames are present), an attacker can use any name-constrained CA to misissue certificates for your domain. That is, nameConstraints (as defined in RFC 5280) restrict the domain/IP space to be used - for example, if I have a nameConstrained CA for example.com, I can only issue certs for example.com and domains below it. This is because every subjectAltName is supposed to be evaluated against the nameConstraint to make sure it's compatible with the constraint - certificates that aren't are not trusted. However, if the software supports matching against the commonName, these commonNames bypass name constraints, meaning I could issue a certificate for  victim.test and it'd be accepted, even though it shouldn't be.

Supporting commonName matching at all presents real risk, and that's why it's been deprecated for two decades. https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo has further details and discussion.