Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Problem: Web UI via HTTPS
#11
(12-31-2023, 06:04 PM)bump_here Wrote:
(12-30-2023, 10:17 PM)ubergoober Wrote:
(12-30-2023, 09:55 PM)Tim Curtis Wrote: I think Lets Encrypt is for Internet hosts and not local hosts like moOde. AFAIK for local hosts a self-signed cert needs to be used and then added to the OS Trust Store since there is no root CA for self-signed certs.

One challenge for moOde HTTPS is that the user chooses the host name (domain name) for a given moOde host and its this domain name that is assigned to the Common Name attribute when the cert is created, thus each moOde host needs its own unique  cert.

For example the self-signed cert attributes associated with domain name. The IP address is for Access Point (AP) mode.

Code:
# Common Name
commonName  = $HOSTNAME.local

# Subject Alternative Names
DNS.1       = $HOSTNAME.local
DNS.2       = $HOSTNAME
IP.1        = 172.24.1.1

The solution I was referring to in my previous post automates cert creation and installation into NGINX. The second part involving adding the cert to the OS Trust Store is a manual process.

After it's shipped with upcoming 8.3.8 release have a look and see if there is a way to improve it or if needed replace it with something better :-)

I'm happy to give it a look.  There are ways to work around the public/private context.  For instance, as in the previously mentioned Home Assistant use case, they employ Duck DNS in order to obtain a public FQDN for the application.  This is free and can be useful in so many other ways, especially if you're into self hosting or running a home lab.  A cert is a cert whether it's an internet host or private.  it's either trusted or not.

This public FQDN is used during the enrollment process for the Let's encrypt certificate.  Let's encrypt does a check to determine the FQDN resolves and gets an http response. In the case where the host is not actually publicly accessible, they have a workaround that requires a few more steps with your DNS provider, or you can temporarily port forward to your internal host.  I'm not certain whether or not the port needs to remain open to renew a certificate.

I think loading the cert into the browser/OS trust store will be less work for users overall.  Most browsers will only trust a cert for about a year and some will not honor it if it's expiration date extends past a certain number of days. Let's Encrypt issues theirs for only 90 days to work well within these limits.  The downside of giving us encryption is how many forum messages will be appearing a year later   Big Grin.


I use acme.sh and their DNS extensions for providing my LAN hosts with certs (i do run a full domain internally) via the DNS challenge method. It works quite nicely. Happy to help out on this front. I've also got certbot running in a few places where that is easier.

can you share about this how you implement it?

i googling it but found i must add the certificate to the browser one by one for each device i used in lan
Reply
#12
It depends on what your network configuration is like, Are you running a domain internally e.g. mynetwork.co.uk? If so you can use certbot or acme.sh to generate certs that the browser will trust.

if your using devicename.local, then you won't be able to generate trusted certificates as .local is not one that is able to have automatically trusted certificates issued for..
Reply
#13
I've added a PR to add acme.sh to the base build over at https://github.com/moode-player/imgbuild/pull/4

Should give us something to have a tinker with Smile
Reply


Forum Jump: