Broken Luci Https -please help! (Chrome and self-signed cert)

Hi all

I've recently joined the world of openwrt and after some intial challenges thought I was getting on top of it.
Seems that was a bit premature (!) as have hit a major problem trying to get the browsers to accept the https certificates. I spent most of yesterday working on this and have now gone backwards and broken the https part of luci completely it seems – I can now only access it on “http://....”

I’ve be using this guide - https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings

Initially I input it DNS.1 under alt_names of the config file exactly as in the guide and have realized that the value there of “luci.openwrt” is wrong for my install and have changed it to “openwrt.lan”.

Anyway despite doing that I initially having a common name ssl error and then a subject alt names error. I didn’t manage to get it working and took more radical steps like restarting services, uninstalling /reinstalling the uhttpd service , luci-app-uhttpd, luci-ssl-openssl, (maybe also libopenssl-conf, libopenssl1.1) and rebooting numerous times I now seem to have broken https access to the luci interface completely. Ive also clicked the “Remove old certificate and key “ and “Remove configuration for certificate and key “ buttons a couple of times and regenerated the key and certificate a few times.

These are my settings under uhttpd (I note that “Redirect all HTTP to HTTPS” is checked)!

I’ve tried following step 2 of this guide to get it working again to no avail:

https://openwrt.org/docs/guide-user/luci/luci.essentials

So questions/help required:

  1. Is there a series of steps I can take to get https working again?

  2. Once 1) is fixed I’d like to get the certificates being accepted by all browsers per the guide.

  3. Unrelated to this but I noticed that when I update the software packages list in luci they are all coming down in http not https – I’m thinking this is exposed to the recently announced security flaw which I understood was patched in this version of openwrt – have I missed something?

Running OpenWrt 19.07.2

--

Steve

  1. You can try to remove all packages connected to uhttpd, delete the configuration leftovers and reinstall them.
  2. I wouldn't advise you to enable https. Uhttpd is a minimalistic web server which cannot withstand attacks from the internet. If you wish to access Luci over an insecure path, use a VPN or SSH tunneling.
  3. It was patched in the previous version.
2 Likes

Thanks trendy

  1. Do you mean more than I did above?
    Ie the packages I've listed and “Remove configuration for certificate and key"

  2. By "all browsers" I mean that are installed on my pc, I'm not trying to enable remote connection.

  3. Ok, so any idea why it still shows "http" ? See screen shot :

Only uhttpd is responsible for the server part. Most likely uhttpd-mod-ubus will be removed as not needed dependency.
Did you also delete the configurations after removing the packages? There is not exact equivalent of apt purge, the configs are remaining.

Then there is no need for https.

Because the problem was not in the http in the first place.

It has never been changed to https. The package download links have been defined as http (in /etc/opkg/distfeeds.conf ) , as by default the router does not have https capabilities.

The package lists are signed, and that serves as the verification.

Adding https to LuCI does not change other parts of the system.

Ok so I've been able to get Https on Luci working again. I removed the packages and installed them again with the --force-maintainer option to reset the config.

I now am back to the situation where I want to get my pc browsers to accept openwrt as a secure Https site. I'd rather do this for peace of mind in case any iot devices end up compromised etc.

But I've followed this guide to the letter but am still getting "subject alternative name missing" when I get to the certificate in Chrome. Any ideas how to fix? I'd the guide up to date? (I notice that you can't paste in the paths in step 7 which makes me think it was written for an earlier version)

You'll reach a peace of mind much faster, if you accept that this isn't possible.

By default, your router only has a RFC1918 (private) IP address, no official CA will provide you with certs for those. While tricking around with a public (sub-)domain, luci-app-acme and relying on hairpin mode is possible, it's also rather fragile (especially when you need it most, when your router doesn't work as you want it to) and hard('ish) to get working.

The only option left, generating your local CA and certs and then importing those into all of your devices is actually more of a security risk (unless you take it seriously and do it properly, like a big CA should do), than just accepting that your router has a self-signed certificate and making your browser accept that cert as an exception (yes, not all browsers are smart in this regard - firefox more than chrome, but both will do).

1 Like

Just been checking and I noticed that the config per point 7 in the guide has reverted to default. Ie its not referencing my cert and key file that I've generated. I think this is why I'm getting the invalid certificate error.

I've just tried to set the paths again in Luci and it fails to confirm and tries to roll back. Think this is my issue. Question is why does it do that?
Any ideas much appreciated!

Sorry Slh posts crossed. So are you saying that the guide I referenced is out of date/doesn't work?

Or is it just that my issue relates to my last post?

Also, after a lot of work configuring HTTPS you will find you can’t access LuCI on mobile devices any more because in that tutorial they only provide a way to generate a certificate for Chrome or Edge on Windows/Linux PC. I’m a little bit regretting spending several hours to enable HTTPS on OpenWrt.