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/emailAddressfirstname.lastname@example.org
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?