NET::ERR_CERT_INVALID from Google Chrome in macOS Catalina

biangbiangmian · October 15, 2019, 4:36am

Recently started getting NET::ERR_CERT_INVALID in Chrome, unsure what I did. I have already tried a make dirclean. Is there any way to somehow reset this in the build system?

From the Chrome error:

When Google Chrome tried to connect to 192.168.1.1 this time, the website sent back unusual and incorrect credentials.

Crucially, I cannot just "proceed to this site anyway" with this particular error, although other browsers just let me bypass it.

192.168.1.1 normally uses encryption to protect your information. When Google Chrome tried to connect to 192.168.1.1 this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be 192.168.1.1, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit 192.168.1.1 at the moment because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later

hnyman · October 14, 2019, 4:55am

The certificate is created on the fly at router during the first boot after flashing (if there is no previous certificate from sysupgrade).

So your comment about "building a different target" goes to wrong direction. Build system had only impact on creating teh SSL libraries for the firmware, but it has no knowledge about teh actual certs.

In normal config the SSL cert is stored in /etc/uhttpd.key and uhttpd.crt files (hopefully I got the exact name right). You can delete those two files and restart the uhttpd service to create new SSL certs.

biangbiangmian · October 14, 2019, 10:59pm

Same problem after deleting the cert, key and restarting uhttpd.

Possibly relevant

Apple: Requirements for trusted certificates in iOS 13 and macOS 10.15

Update: it seems to be an issue on my main development machine. Other devices are able to access it just as before. Recently upgraded to macOS Catalina (some possibly relevant information here), and iirc that's when it started. I'll post more if I can narrow down the issue.

4+0 records in

4+0 records out

Generating RSA private key, 2048 bit long modulus

Generating selfsigned certificate with subject 'C=ZZ,ST=Somewhere,L=Unknown,O=OpenWrt1b20*

d3,CN=OpenWrt,' and validity 20191011055349-20211010055349

hnyman · October 14, 2019, 7:21am

Possibly this bit from that link:
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Or some other of the criterias. Likely the self-signed certificates fail one or more of those criterias.

Ps. You might edit the topic title to contain MacOS Catalina ...

biangbiangmian · October 14, 2019, 11:03pm

Can confirm that the issue is only affecting my one mac that has been upgraded to macOS Catalina. Debian and Ubuntu hosts are fine, as are android and iOS devices. It could simply be my particular computer, but to be sure I better set up some VM's to test.

Anyway, I will generate a new certificate in accordance with the stated requirements, test it, and report back.

biangbiangmian · October 15, 2019, 1:30am

I am not seeing the issue when using an older firmware build. The issue is resolved when generating a certificate using the instructions on this page. It seems a Teltonika RUT955 running RUT9XX_R_00.06.04.3 has the same problem.

biangbiangmian · October 15, 2019, 4:46am

A couple of workarounds at the moment

use --ignore-certificate-errors flag when starting Chrome
use another browser such as Safari or Firefox.
use another OS

I have not been able to reproduce the issue on iOS yet, although according to Apple it should be affected

hnyman · October 15, 2019, 5:10am

The current certificate creation command is a simplified shortcut and creates slightly incomplete certificates without all possible fields, and apparently your Chrome now frown upon it in its validity checks.

hnyman · October 15, 2019, 6:04am

You can look at the cert creation logic in

github.com

openwrt/openwrt/blob/master/package/network/services/uhttpd/files/uhttpd.init#L34


	local cfg="$1"
	local var="$2"
	local opt="$3"
	local def="$4"
	local val


	config_get_bool val "$cfg" "$var" "$def"
	[ "$val" = 1 ] && procd_append_param command "$opt"
}


generate_keys() {
	local cfg="$1"
	local key="$2"
	local crt="$3"
	local days bits country state location commonname


	config_get days       "$cfg" days
	config_get bits       "$cfg" bits
	config_get country    "$cfg" country
	config_get state      "$cfg" state
	config_get location   "$cfg" location

It originally supported only creating cert by using a small "px5g" tool with minimal functionality, and that is the OpenWrt default. I extended the functionality in 2016 to support also OpenSSL as the creation tool, but I kept the cert content/logic similar to px5g.

In theory it could be changes/extended for at least openssl, so that it would first write the conf file to /tmp and then use that as a parameter in the creation command. But I did not bother at that time, as the certs in any case a re self-signed, so that you need an exception in Firefox in any case, etc.

biangbiangmian · October 15, 2019, 6:30am

This is exactly what I started trying to do earlier today, because I think it needs to at least be passed EKU = serverAuth, but there is no way to directly do that from the openssl command with a parameter, you need the config file.