The certificate is signed with our internal CA, which is installed in the system store (by putting it in /usr/local/share/ca-certificates). I checked the site with both Firefox 52 and openssl s_client -verify 5 -verify_return_error -connect git.ourdomain.net:443; both are happy. OpenSSL shows the chain as:

Both OpenSSL and Firefox show strong signing (SHA-512) and ciphers (AES-GCM). The certificate (according to openssl x509 -text) is sha512WithRSAEncryption, with a 4096-bit RSA key. It has a Netscape Cert Type of SSL Client, SSL Server.

Note: «us» and ourdomain.net are redactions; the actual output has our company name for «us» and our actual domain for ourdomain.net. I carefully checked that all the ourdomain.net actually match.

As far as I can tell, there is nothing wrong with the certificate, and the common name (git.ourdomain.net) is perfectly valid and matches the URL—so what is Chromium complaining about? And, presuming it's not a real issue, is there some way to override it?

1 Answer
1

It appears from Chromium bug 308330 that they believe there is a risk of a false match when matching hostnames to certificate common names, and thus have disabled that. Chromium will now only match against the subjectAltName extension. Firefox made a similar change, but limited it to only newer certificates issued by public CAs, not internal ones. That's why Firefox still works.

The Chromium change can be overridden by setting the policy EnableCommonNameFallbackForLocalAnchors, which can be creating /etc/chromium/policies/managed/use-common-names.json with content like:

Using CN for the hostname was already deprecated in the year 2000, see RFC 2818 section 3.1.
– Steffen UllrichMay 1 '17 at 18:37

@SteffenUllrich That same section says that the common name MUST be checked as well if there is not a SAN... I read through that whole bug report. It seems what they've done is perfectly reasonable for public CAs, though they really ought to have given some warning for internal ones (which had better not be issuing certificates with browser-confusing common names!) And it'd be nice if OpenSSL didn't require writing a conf file to use SAN. But yeah, ultimately I need to re-issue that cert. And probably a few others.
– derobertMay 1 '17 at 18:43

It would definitely be good if the deprecation was not only left rotting in the RFC but that clients would have screamed (but accepted) earlier on such certificates so that users and authors of tutorials actually got notice of the deprecation.
– Steffen UllrichMay 1 '17 at 19:05

@SteffenUllrich agreed. Also if Chromium had a better error message, but I gather from the linked bugs that's already being fixed.
– derobertMay 1 '17 at 19:20