Https connection to LuCI is discarded

Installing and Using OpenWrt
21

One is using a cert for a public server vs. using a cert for a private LAN IP (router).

22

Works on my browser, when you actually add them (i.e. on the Chrome and Firefox screens in Post No. 9).

23

no it does not work out of the box. that's the problem ... well, actually we should not treat it as a problem because it totally makes sense why browsers raise a warning for any ( ! ) self signed cert signed by unknown CA. it is not just openwrt "problem".

and yes, you have couple of ways to resolve :

  1. create/use a private CA, add to client's trusted CA store and create/use server certs signed by this private CA,
  2. just add openwrt to client's exception list - that's the easiest imho. if we are talking about usual home usage it should not be an issue if from a trusted PC you own connect to your own router through your own network and you just will not see the lock badge in browser ... for any other case you may prioritize security of course and use e.g. the commercial method (next point).
  3. use commercial (paid or free) CA to sign server cert for your router.

and no, let's encrypt does not require you to be on internet only for the time when the cert is (re)issued and http based validation is used. or you can use DNS based validation without ever open up to internet.

24

I'm guessing you were responding to someone else.

I was merely assisting the OP with option No. 2 (as noted in the Wiki).

I personally think it's silly to know why the router is given the error and try to cancel it.

25

ok, in your previous post it looked you were disagreeing with my statement about self signed certs. but my statement still holds as explained: by design any unknown self signed cert is not accepted by any modern browser for good reason.

(/off: your last link is actually the problem: some people misunderstand having a public (e.g. let'sencrypt) certificate would mean you can open up your router to WAN. it is not the case.
if somebody would like remote access to their router than should use VPN, a public cert is not enough.)

1 Like
26

Hello im new to openwrt after follow the tutorial https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings i lost connection to web interface can you help me on this please?

27

I sorted by following this tutorial https://openwrt.org/docs/guide-user/troubleshooting/backup_restore using the cli.

28

Following the guide, I can create a certificate and add it to Firefox as an execption when visiting my router's webadmin and everything works.

However, for Chrome based browsers, it does not suceed. When I do no install the certificate, they allow me to manually allow to visit the site. However, when I install the certificate, I get a "NET::ERR_CERT_INVALID" error and I cannot manually override it. I have no idea what I am doing wrong, has Chrome becamoe more strict again or something?

Edit: I am on Linux, Kubuntu 22.04 specifically.

29

Browsers are increasingly strict in accepting SSL certificates.
That has been noticed earlier, and there is both a LuCI issue and a PR trying to mitigate at least some parts of the problem.

1 Like
30

I see. However I am running into this error even if I do what I am supposed to do acording to the github issue (so it seems it would not help me).

I have this file supi_hnizdo.conf:

[req]
distinguished_name  = req_distinguished_name
x509_extensions     = v3_req
prompt              = no
string_mask         = utf8only

[req_distinguished_name]
C                   = world
ST                  = state
L                   = city
O                   = myorg
OU                  = myunit
CN                  = supi_hnizdo.lan

[v3_req]
keyUsage            = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage    = serverAuth
subjectAltName      = @alt_names

[alt_names]
DNS.1               = supi_hnizdo.lan
IP.1                = 192.168.2.1
IP.2                = 2a03:a900:1000:22b1::1
~

I then run:

openssl req -x509 -nodes -days 365 -newkey ec:<(openssl ecparam -name prime256v1) -keyout supi_hnizdo.key -out supi_hnizdo.crt -config supi_hnizdo.conf
/etc/init.d/uhttpd restart

my /etc/config/uhttpd is like this:

config uhttpd 'main'
        list listen_http '0.0.0.0:80'
        list listen_http '[::]:80'
        list listen_https '0.0.0.0:443'
        list listen_https '[::]:443'
        option redirect_https '0'
        option home '/www'
        option rfc1918_filter '1'
        option max_requests '3'
        option max_connections '100'
        option cert '/etc/ssl/supi_hnizdo.crt'
        option key '/etc/ssl/supi_hnizdo.key'
        option cgi_prefix '/cgi-bin'
        list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
        option script_timeout '60'
        option network_timeout '30'
        option http_keepalive '20'
        option tcp_keepalive '1'
        option ubus_prefix '/ubus'

config cert 'defaults'
        option days '730'
        option key_type 'ec'
        option bits '2048'
        option ec_curve 'P-256'
        option country 'ZZ'
        option state 'Somewhere'
        option location 'Unknown'
        option commonname 'OpenWrt'

On my machine, I run

scp root@192.168.2.1:/etc/ssl/supi_hnizdo.crt . 
certutil -d sql:$HOME/.pki/nssdb -A -t "CT,C,c" -n supi_hnizdo -i supi_hnizdo.crt

And then I get the ""NET::ERR_CERT_INVALID" without being able to override it (unless I type "thisisunsafe").

If I run certutil -d $HOME/.pki/nssdb -D -n supi_hnizdo

I can then override the error (after each time I run certutil, I restart the browser). This is all on Chrome, Firefox just accepts the certificate and is happy. I forgot to add I am on 23.05 on Belkin RT3200.