1

I'm trying to figure out why Chromium is not happy with a TLS certificate, and how to fix it:

After upgrading & restarting Chromium (now 58.0.3029.81, running on Debian testing), I can no longer access our internal GitLab server (installed on Debian Jessie, via the omnibus package). I get:

Your connection is not private

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

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:

Certificate chain
 0 s:/C=US/ST=Virginia/L=Sterling/O=«us»/OU=Servers/CN=git.ourdomain.net
   i:/C=US/ST=Virginia/L=Sterling/O=«us»/CN=«us» Certification Authority/emailAddress=ca@ticket.ourdomain.net

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?

Improve this question
3

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:

{
    "EnableCommonNameFallbackForLocalAnchors": true
}

It seems that you have to restart Chromium after creating that.

Improve this answer
4
  • Using CN for the hostname was already deprecated in the year 2000, see RFC 2818 section 3.1. – Steffen Ullrich May 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. – derobert May 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 Ullrich May 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. – derobert May 1 '17 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.