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

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


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

Chromium Bug 308330
Google's post of intent to remove
Toggle State Changes


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

So there's out culprit. I'll have to adjust it an look at regenerating the existing certs. Coincidentally, some expire this year anyway
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

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

Looks good. So just need to renew certs and re-test now
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
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

Will just need to work around the other services now
btasker added 'Certificates Chrome HTTPS SSL' to labels
btasker changed Project from 'STAGING' to 'Miscellaneous'
btasker changed Key from 'STGNG-6' to 'MISC-20'
btasker added 'Chrome reporting Invalid Common Name' to Version
btasker added 'Chrome reporting Invalid Common Name' to Fix Version
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.
btasker changed status from 'Open' to 'Resolved'
btasker added 'Fixed' to resolution
btasker changed status from 'Resolved' to 'Closed'