Https connection to LuCI is discarded

I believe the Wiki is clear and well done :smile:

1 Like

applied certificate on my ubuntu via certutil. Still have error from both firefox and chrome. Documentation sucks :frowning:

Firefox:
The certificate is not trusted because it is self-signed.


Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

Chrome: see picture:

Which is correct.

The browsers won't accept a self signed cert until you override the warning.

If you want to use HTTPS, look in to Let's Encrypt.

1 Like

Did you actually add it to Firefox and Chrome (i.e. the cert managers you're using)?

that's totally ok: self signed certificates are not accepted as @anon89577378 already confirmed.

you have basically two paths to choose:

  1. keep using the self signed cert which was created by openwrt and make an exception in your browser: https://it.nmu.edu/docs/adding-security-exception-your-browser. this will make your browser not complaining any further.
  2. use a real (commercial or free, e..g let's encrypt) certificate which will be trusted by any browser.

@icegood, the simplest way to create self signed key/cert pairs would be:

enter to your router CLI from your computer (Windows or Linux) just type this in a Windows Powershell or Linux bash:

ssh root@192.168.1.1

Then type this:

cd /etc
# Create CA key and certificate. Import ca.crt as root certificate to the computers accessing the router and save ca.key for future use.
[ -e "./ca.key" ] || openssl genrsa -out ca.key 2048
[ -e "./ca.crt" ] || openssl req -new -x509 -days 7300 -key ca.key -subj "/C=CN/ST=GD/L=SZ/O=Acme, Inc./CN=Acme Root CA" -out ca.crt

# Create server key and certificate. use server.key and server.crt as valid files for uhttpd, ttyd, etc.
[ -e "./server.key" ] || openssl req -newkey rsa:2048 -nodes -keyout server.key -subj "/C=CN/ST=GD/L=SZ/O=Acme, Inc./CN=localhost" -out server.csr
echo "subjectAltName=IP:192.168.1.1,DNS:Openwrt.lan,DNS:myserver.myddns.org,DNS:www.myserver.myddns.org" > /tmp/subjectAltName.txt
openssl x509 -sha256 -req -extfile /tmp/subjectAltName.txt -days 825 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

Obviously, change the DNS entries with your own internal/external, and IPs you use to access the router.

Do not forget to transfer the ca.crt file out of your router and add it as root certificate to your computer, phone, or any other device you use to browse LuCI web interface.
From your computer (Windows or Linux) just type this in a Windows Powershell or Linux bash:

scp root@192.168.1.1:/etc/ca.crt .

In Windows you just have to double click the ca.crt file and add it to the trusted root certificates storage.

/etc/server.key and /etc/server.crt can be used for any service such as uhttpd, ttyd, nginx, etc.

I think your problem is that the subjectAltName is missing in your certificate. So, you can only access your router using the CN, and that CN doesn't look like a valid DNS in your lan.

For windows, the guide is correct.
However, for linux, is a totally different matter.
To get chrome work, is sort of easier, for firefox is a bit more complicated.
For those interested, i can share my own guide, which works.
1)Chrome

sudo apt update
sudo apt install libnss3-tools

Syntax

certutil -d sql:$HOME/.pki/nssdb -A -t "TC,," -n "<CERT_NICKNAME>" -i <FILE_CRT>

From the Folder where the .crt is, open Terminal
OpenWrt

certutil -d sql:$HOME/.pki/nssdb -A -t "TC,," -n "OpenWrt" -i mycert.crt

2)Firefox

Syntax

certutil -A -n "<CERT_NICKNAME>" -t "TC,," -i <PATH_FILE_CRT> -d sql:<PATH_PROFILE_FIREFOX>

CERT_NICKNAME: Certificate Alias to set on the certificate list
PATH_FILE_CRT: Path to the .crt file to import
PATH_PROFILO_FIREFOX: Path to the firefox profile used, to be found in /home/user/.mozilla/firefox/Profile_name
example:

certutil -A -n "OpenWrt" -t "TC,," -i /home/OpenWrt/mycert.crt -d sql:/home/user/.mozilla/firefox/qspzdclg.default-release
qspzdclg.default-release

I believe that it is way easier than that.

After running the creating process of my previous post here, do this on your computer depending on your OS:

Windows:

scp root@192.168.1.1:/etc/ca.crt .
certutil -addstore -f "ROOT" ca.crt

Linux (Debian, Ubuntu, WSL...):

scp root@192.168.1.1:/etc/ca.crt .
sudo cp ca.crt /usr/local/share/ca-certificates/ca.crt
sudo update-ca-certificates

MacOS X:

scp root@192.168.1.1:/etc/ca.crt .
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ./ca.crt

Well, the certificate creation isnt so much different.
Maybe i could use your way to nstall the certificate anyway?
The way i do, i end up whit the ca.crt anyway, so doing your commands i should get the same results, i suppose?
Or your installation guide is different?

Installing a new system root certificate is not recommended. If anyone has the key to that certificate, they can use it to sign phony certificates to MITM any web site on any application on your PC.

It is much safer to set an internal browser exception for one private IP address, that of your router.

Realize that SSL does nothing to deter hacking of the server. It protects the user from having private data intercepted or connecting to a rogue server. Generally these aren't likely on a home LAN.

3 Likes

No need for that if you delete the ca.key file after the server.key and server.crt are created. Still easier and as safe as creating exceptions. And you are covered everywhere. For instance in Linux you can test the validity of the cert of a website by doing:

openssl s_client -showcerts -connect SITE_NAME_HERE:443 | openssl x509 -noout -dates

IMO, Let's Encrypt certs are the way to go.

The only problem of Let's Encrypt is that your server must be public, so your FQDN. So, you lose the flexibility of using the external and internal names and IPs in the certificate. In other words, you won't be able to secure access your router using the lan IP, or local lan name.

Which goes back to @mk24's post above -

1 Like

I don't see the connection. One thing is where you get the CA cert from, and the other is the way you trust on that cert. Two different discussions.

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

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

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.

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.

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