Thanks to all the developers hard work on bringing this new RC out.
I have successfully installed on my Gl.Inet GL-MV1000 (brume). It seems to be working just fine. I was able to add necessary WireGuard packages and was able to connect to TorGuard VPN without problem.
I'm about to start installing other packages (nano, VPN-Policy-Based-Routing, SQM) and will report back if I find any problem. For now, it's still behind my current main router, but I intend to set it up as main router once I finish all the intended configuration.
In the meantime, kudos to everyone involved in bringing this out.
I have a problem with creating ip rules in 21.02rc2. The invert seems to be ignored in the following definition.
uci set network.unmarkedThroughTable=rule
uci set network.unmarkedThroughTable.mark="0x888"
uci set network.unmarkedThroughTable.invert='1'
uci set network.unmarkedThroughTable.lookup='200'
ip rule list shows 1: from all fwmark 0x888 lookup 200 (21.02rc2)
instead of the correct 1: not from all fwmark 0x888 lookup 200 (19.07.7)
@Torxgewinde with your tp-link archer c2600 v1 did you experience any high latency ping to say 192.168.1.1 before setting scheduler set to performance?
Let me ask my question more specifically. It is about a CERTIFICATE that Chrome says is inadequate. (I am not asking if Luci works with Chrome -- it does -- once you get past the invalid certificate). Here are the error messages:
This page is not secure (broken HTTPS).
Certificate - Subject Alternative Name missing
The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.
This site is missing a valid, trusted certificate (net::ERR_CERT_INVALID).
It seems to me that Luci uHTTPd needs some extra fields, e.g. for Subject Alternative Name so that it can generate a certificate that Chrome will trust.
OpenWrt can't provide a certificate that Chrome will trust, because it cannot be signed. To get a signed certificate you need a domain, and something like Let's Encrypt. But even if a domain could be generated on the fly (somerandomdomain.openwrt.org or something like that) it still could not work out of the box, because you need Luci to create a working WAN first, to be able to fetch a domain, and ask Let's Encrypt to sign the certificate. And then you should have to access your router via somerandomdomain.openwrt.org, and how would you know the domain?
I did not really pay attention to that detail, but top of my head there was no such thing like a high latency ping.
It just crashed randomly and with the scheduler set to performance my issues vanished. I have three of those devices in operation 24/7 and for all it was "the fix" against reboots.
Mijzelf, thanks for your reply. I can see that perhaps "out of the box" is not possible. But perhaps there could be a "push a button" type possibility that is not far from reach. When I have the Luci uHTTPd page up, there is a button to push that generates a certificate, just not one that Chrome will accept. The form looks like what is below. Why not add the necessary fields to the form to make a compliant certificate, rather than a non-compliant one?
jeremy
p.s. I tried to follow the steps in this script but kept running into errors with the script that I could not understand. I could not get the script to run to completion.
No, the hen and egg problem remains - and you would still have to provide your own domain name (OpenWrt providing one for you 'for-free' not only would require a hell of a lot administriva and infrastructural issues (both in soft- and hardware), but also a legal can of worms, so that's not going to happen). You'd also need a working rtc on your router (kind of difficult to generate valid certificates without time), working WAN connectivity before connecting to your router the first time (telepathic credential exchange for PPPoE or other WAN protocols sounds kind of difficult) and a means to communicate the 'generated' (again, not going to happen) domain name for you to connect to (does your router have a display?). Also what happens if you haven't used your router for a while, powered-off, certificate expired, WAN now needs different access credentials, etc. --> fun.
Having a valid SSL certificate, signed by an officially recognized CA sounds all great, until you dig into the details of how to make this working.
If you still want to do it, luci-app-acme exists, but you need to configure it first - and even then it doesn't work reliably enough, but feel free to try it yourself or to add new features or fix its bugs.
(I guess it should be in its own thread as it has nothing specific to the release candidate)
There are 2 different, although related, concerns here:
Compliance to RFC 6125, which Chromium now enforces (see the initial discussion). Basically, it does no longer accept the use of the commonName field of a certificate for "matching" the entity to be validated, and instead requires the use of the subject alternative name extension (OID 2.5.29.17, see RFC 5280). The gist is that the commonName field is an unstructured text field, as opposed to OID 2.5.29.17.
In that regard, OpenWrt/LuCI could indeed be enhanced/modified to use the subject alternative names (SAN) extension, but it would need to add some logic for handling multiple values and to differentiate between domain name and IP address (because subject alternative names is can contains different name types), as specified in the RFC (see dNSName and iPAddress):
The lack of SAN from an OpenWrt-generated certificate can be verified with the openssl x509 command:
$ echo | openssl s_client -connect 192.168.1.1:443 -showcerts | openssl x509 -noout -text
Can't use SSL_get_servername
depth=0 C = ZZ, ST = Somewhere, L = Unknown, O = OpenWrta54761ee, CN = OpenWrt
verify error:num=18:self signed certificate
verify return:1
depth=0 C = ZZ, ST = Somewhere, L = Unknown, O = OpenWrta54761ee, CN = OpenWrt
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5f:17:6f:30:92:9e:f3:f7:4a:73:54:7b:27:3e:66:04
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = ZZ, ST = Somewhere, L = Unknown, O = OpenWrta54761ee, CN = OpenWrt
Validity
Not Before: May 26 10:17:03 2021 GMT
Not After : May 27 10:17:03 2023 GMT
Subject: C = ZZ, ST = Somewhere, L = Unknown, O = OpenWrta54761ee, CN = OpenWrt
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:06:da:44:fa:ba:20:e3:18:7c:78:65:eb:ba:36:
9f:20:6f:3f:0f:f5:2e:98:79:18:4e:c5:32:a7:3c:
ee:b1:07:fc:7a:93:9c:dc:17:7c:5e:e2:3d:fe:ad:
7e:32:28:53:22:b0:18:bd:18:80:69:c3:a1:0d:2c:
26:ee:df:6d:e0
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:6a:df:ef:77:7a:54:a3:3b:f4:71:e3:ec:bd:de:
32:47:30:a9:78:02:db:48:b2:9f:68:4c:e1:a5:89:ab:16:5f:
02:20:21:19:29:42:df:60:12:7e:1c:5e:3a:ee:0a:73:f2:e0:
77:13:66:93:c2:7d:3d:dc:32:09:19:2a:11:fe:bb:c5
The other concern is PKIX trust chain validation, which is outside the scope self-signed certificate generation feature captured by the screenshot from roschelle63. As highlighted by Mijzelf/slh, it is "doomed" to fail by the very nature of self-signed certificates (unless you somehow import the provisioned certificate into your OS/browser CA store).
As with most kinds of security-related checking, should any of the underlying validation fail, the end result is to fail the global validation, and in the case of a browser, show a security warning.
So the problem becomes: should OpenWrt self-signed certificate generation follow RFC 6125 and put the hostname and/or IP address in SAN, knowing that fixing that issue will not address the overall concern of browser warning (because trust validation will fail)?
Since upgrading from 21.02.0rc1 to rc2 on my tplink c2600 I have got random reboots - every og every second day. It is not clear to me, if it is related to huge trafic or any other load.
