MISC-20: Chrome Reporting Invalid Common Name for (apparently) Valid Certificates

Issue Information

Issue Type: Bug
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: Miscellaneous (MISC)
Resolution: Fixed (2017-04-30 20:25:29)
Affects Version: Chrome Issues,
Target version: Chrome Issues,
Labels: Certificates, Chrome, HTTPS, SSL,

Created: 2017-04-30 19:36:46
Time Spent Working


Description
I use a Certificate Authority to issue certificates for various services.

However, on one of my devices, Chromium has started reporting that the Common Name is invalid

NET:ERR_CERT_COMMON_NAME_INVALID


Viewing the certificate in dev tools (where the functionality has now been inconveniently hidden) the Common Name definitely matches the service being accessed.

This affects all services I've issued a cert for, but only in Chromium on that device.

The version is 58.0.3029.81

A version running 57.0.2987.98 is unaffected and reaches the sites fine.

Something has presumably changed in Chrome/Chromium


Issue Links

Causes LAN-102: Revoke and Renew Certificates
Chromium Bug 308330
Google's post of intent to remove
Toggle State Changes

Activity


2017-04-30 19:43:46
Looks like it's a product of feature deprecation in Chromium's 308330

Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.


The scripts I've been using (basically easy-rsa) don't set SANs 
ben@milleniumfalcon:/tmp/hlstest$ echo | openssl s_client -connect creds.bentasker.co.uk:443 -servername creds.bentasker.co.uk 2>&1 | openssl x509 -noout -text | grep DNS
ben@milleniumfalcon:/tmp/hlstest$


So there's out culprit. I'll have to adjust it an look at regenerating the existing certs. Coincidentally, some expire this year anyway

2017-04-30 19:46:00
There's also a thread in Google's product forums - https://productforums.google.com/forum/#!topic/chrome/zVo3M8CgKzQ;context-place=topicsearchin/chrome/category$3ACanary%7Csort:relevance%7Cspell:false - the main complaint seems to be the same as mine, that the error message itself is badly thought out. It's not that The Common Name is invalid, it's that Common Name is invalid, see? Would've been far better to have a name_not_in_sans or something


2017-04-30 19:57:08
OK, SANs aren't supported in EasyRSA 2.0, but there is a patch available here - https://github.com/cvut/gentoo-overlay/blob/master/app-crypt/easy-rsa/files/easy-rsa-2.0.0-san.patch 

$# patch < easy-rsa-2.0.0-san.patch 
patching file openssl-0.9.6.cnf
patching file openssl-0.9.8.cnf
patching file openssl-1.0.0.cnf
Hunk #1 succeeded at 195 (offset 1 line).
Hunk #2 succeeded at 217 (offset 1 line).
patching file pkitool
patching file revoke-full
patching file README.subjectAltName


Testing whether it's actually worked 
# ./build-key-server test.example.invalid

# openssl x509 -in keys/test.example.invalid.crt -noout -text | grep DNS
                DNS:test.example.invalid


Looks good. So just need to renew certs and re-test now

2017-04-30 20:05:56
Incidentally, it looks like Firefox has actually been enforcing this since version 48, but they've taken a slightly saner route and not enforced it for any certs signed by an imported root - https://bugzilla.mozilla.org/show_bug.cgi?id=1245280

2017-04-30 20:20:42
I really don't like the easy-rsa renewal process. Having to revoke an existing certificate before you can issue a new one means there's no window to deal with issues.

Worse, because I forgot about that requirement, build-key-server truncated the existing cert file, so when then trying to revoke, I got 
# ./revoke-full creds.bentasker.co.uk
Using configuration from /usr/share/nginx/credlocker/conf/CA/easy-rsa/openssl-1.0.0.cnf
unable to load certificate
3069535440:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE
Using configuration from /usr/share/nginx/credlocker/conf/CA/easy-rsa/openssl-1.0.0.cnf
unable to load certificate
3069158608:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE


Copying the old cert back to that file resolved, so then its 
# ./revoke-full creds.bentasker.co.uk
Using configuration from /usr/share/nginx/credlocker/conf/CA/easy-rsa/openssl-1.0.0.cnf
Revoking Certificate 05.
Data Base Updated
Using configuration from /usr/share/nginx/credlocker/conf/CA/easy-rsa/openssl-1.0.0.cnf
creds.bentasker.co.uk.crt: C = UK, ST = Suff, L = Ips, O = BTasker, OU = BTasker, CN = creds.bentasker.co.uk, name = BTasker, emailAddress = mail@<Domain Hidden>
error 23 at 0 depth lookup:certificate revoked

# ./build-key-server creds.bentasker.co.uk


Deployed the cert, and Chrome's stopped whinging

Verified the SAN is included 
ben@milleniumfalcon:~$ echo | openssl s_client -connect creds.bentasker.co.uk:443 -servername creds.bentasker.co.uk 2>&1 | openssl x509 -noout -text | grep DNS
                DNS:creds.bentasker.co.uk


Will just need to work around the other services now

2017-04-30 20:21:24
btasker added 'Certificates Chrome HTTPS SSL' to labels

2017-04-30 20:22:33
btasker changed Project from 'STAGING' to 'Miscellaneous'

2017-04-30 20:22:33
btasker changed Key from 'STGNG-6' to 'MISC-20'

2017-04-30 20:22:41
btasker added 'Chrome reporting Invalid Common Name' to Version

2017-04-30 20:22:48
btasker added 'Chrome reporting Invalid Common Name' to Fix Version

2017-04-30 20:25:14
Have moved this issue into the publicly available MISC project, as I almost certainly won't be the last to be bitten by this.

Still wish they'd thought more about the error they're returning, if only so you don't end up googling "Chrome reports invalid common name when it's not". Googling the exact error message will, of course, give you lots of hits for why a common name might be invalid, which also isn't helpful given the specific cause in this instance.

2017-04-30 20:25:29
btasker changed status from 'Open' to 'Resolved'

2017-04-30 20:25:29
btasker added 'Fixed' to resolution

2017-04-30 20:25:33
btasker changed status from 'Resolved' to 'Closed'