Google Chrome 58 making NET::ERR_CERT_COMMON_NAME_INVALID all over the place

We use self signed certificates at LeadSift for our dev and qa servers behind the firewall and have our team just import the certificate into their computers. Recently after months of it working just fine, I got an error on Google Chrome which looked like this.

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

This server could not prove that it is site.dev.leadsift.com; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection. Learn more.

After a bit of googling, turns out that in Chrome 58 (released April 19 2017) introduced some changes that breaks certificates that do not have use Subject Alternative Names. The common name field is (used to be) the common way to identify your website in SSL certs. New to me, but turns out to be relatively old, the common name field has been phased out in 1999 to be replaced with the x509 Subject Alternative Names (SAN) extension field. Support for this field has only started gaining adoption in 2007. What changed recently is google decided to go ahead and remove the 20 year old deprecated (meaning slated for remove) common name fields (how could they right 😛 ).

Since most tutorial and articles on how to use openssl do not even mention SAN. Moreover, adding SAN to your openssl commands is really clunky and most current tutorials ask the user to edit global config files to add SAN to the certs, very few people have added SAN to their self signed certificates. The good news is all (guessing here, its at the very least a “most“) SSL certificates issued by a CA already have SAN added to them. Hence, the internet didn’t break two weeks ago 🙂 when google pushed this update.

tlDr; Well then, how do you solve this?! … ok 🙂

Solution #1 – #HACK – get chrome to accept the old cert

Tell everyone who needs to access your site to change their chrome settings to revert back to the Common Name field rather than the SAN field. More info on that can be found in the Chromium documentation https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors

I do not like this solution so won’t divulge further into how to do it here. the link above should be sufficient.

Solution #2 –  Re-generate your certificate

I spent sometime getting my certs to generate with SAN in a nice way, without having to hack the global openssl conf file. What I did instead is create a local conf file that you can pass into the openssl commands.

Here is this allusive conf file, an added benefit of this conf is that you no longer need to manually type out the answers to those openssl questions. The following config will result in a wildcard cert with SAN. Change the values as necessary to your setup.

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name      = dn
# The extentions to add to the csr
req_extensions = v3
# The extentions to add to the self signed cert, if generating as part of req
x509_extensions = v3

[ dn ]
C=CA
ST=Nova-Scotia
L=Halifax
O=LeadSift Inc.
[email protected]
CN = *.dev.leadsift.com

[ v3 ]
basicConstraints = CA:false
keyUsage = digitalSignature, keyEncipherment
subjectAltName      = @alternate_names

[ alternate_names ]
DNS.1   = dev.leadsift.com
DNS.2   = *.dev.leadsift.com

Here are the commands that use this conf file to generate a CSR and then a x509 certificate from the CSR that includes the proper info.

# only if you are generating a new private key 
# openssl genrsa -out dev.key 2048

# generate a csr
openssl req -new -key dev.key -out dev.csr -config config.txt

# generate a self signed root certificate
sudo openssl x509 -req -days 3650 -sha256 -in dev.csr -signkey dev.key  -out dev.crt -extfile config.txt -extensions v3

This cert works fine with Chrome 58 and should be fine for the foreseeable future (or until sha256 is also cracked 🙂 ).

We use self signed certificates at LeadSift for our dev and qa servers behind the firewall and have our team just import the certificate into their computers. Recently after months of it working just fine, I got an error on Google Chrome which looked like this. Attackers might be trying to steal your information from…