+- Moode Forum (https://moodeaudio.org/forum)
+-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3)
+--- Forum: Feature requests (https://moodeaudio.org/forum/forumdisplay.php?fid=8)
+--- Thread: [PROBLEM] Web UI via HTTPS (/showthread.php?tid=5107)
Pages:
1
2
Web UI via HTTPS - bm401 - 10-07-2022
I integrated the moOde Audio in Home Assistant via iframe. This works flawless and doing so I can use all the features the web UI gives me.
However, this does not work when accessing Home Assistant via https because you cannot have an unsecured iframe source in a secure webpage.
Is there an easier way to serve the web UI via https besides adding certificates via SSH and adjust the nginx config?
If I do it manually, I have to repeat it every time I do an update.
Has anyone done this before? How did you do it?
Is this something that could make it into a standard moOde release?
RE: Web UI via HTTPS - Tim Curtis - 10-07-2022
I'm not sure if a Browser trusted cert can be built into moOde.
How are you currently doing it?
RE: Web UI via HTTPS - bm401 - 10-07-2022
I'm not currently doing this. I was looking for a best practice on how to do this without worrying about breaking anything when updating.
I'm fine with a self signed certificate.
A workaround for me at this time is to do TLS termination using nginx on the machine that is running Home Assistant. This to me has some security drawbacks because that machine is exposed to the Internet and I worry about having the raspi with moode exposed by doing that.
RE: Web UI via HTTPS - ubergoober - 12-28-2023
@bm401 you could take a different approach. Look into Cloudflare and the Cloudflared Home Assistant Addon. Cloudflare can act as a secure proxy for insecure web applications. it will ennforce SSL, even wrap password security and two factor authentication around apps that don't use certificates or SSL. In this case you could position Home Assistant as an insecure app, secure it with Cloudflare and then on the home network see if your iframe works. I'm running the add on and use its cloudflare endpoint with the home assistant app for android, so I don't think you'd be losing any functionality. Other integrations would have to be examined on a case by case basis.
Goood luck.
RE: Web UI via HTTPS - Tim Curtis - 12-28-2023
There is an experimental feature "HTTPS-only mode" already built into moOde but I haven't tested it in a long while and it looks like a necessary command file "gen-cert.sh" that is part of the feature was omitted from the /var/www/util directory in production releases.
The feature un-hides an option on System Config to turn on HTTPS-only mode This results in a self-signed cert for $HOSTNAME.local being automatically generated during startup and NGINX being configured to run in HTTPS-only mode.
IIRC the big problem are the nasty Browser warnings that appear due to self-signed cert.
RE: Web UI via HTTPS - Tim Curtis - 12-28-2023
After looking at the feature code and running some tests there were some missing pieces but once those were restored things started working. The cumbersome part is adding the self-signed cert to the OS root store which eliminates the Browser warnings. This process differs on Mac/Win/Linux and so its kind of a mess.
I think it might be ok to release this as an "experimental" feature for upcoming 8.3.8 Bullseye. Maybe someone can figure out how to automate or document adding the self-signed cert to the OS specific root store.
RE: Web UI via HTTPS - ubergoober - 12-30-2023
(12-28-2023, 11:57 PM)Tim Curtis Wrote: After looking at the feature code and running some tests there were some missing pieces but once those were restored things started working. The cumbersome part is adding the self-signed cert to the OS root store which eliminates the Browser warnings. This process differs on Mac/Win/Linux and so its kind of a mess.
I think it might be ok to release this as an "experimental" feature for upcoming 8.3.8 Bullseye. Maybe someone can figure out how to automate or document adding the self-signed cert to the OS specific root store.
Many people are landing on using an acme client and lets encrypt free certificates. Home Assistant relies on Lets Encrypt if you use their duckdns add on. It requires an account with Let's Encrypt. They issue you credentials that you can use with the acme client which automatically renews the certificate for you. This almost makes certificates a "fire and forget" solution. My browswer recognizes Let's Encrypt's root CA, so no worries there, either.
RE: Web UI via HTTPS - Tim Curtis - 12-30-2023
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.1The 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 :-)
RE: Web UI via HTTPS - ubergoober - 12-30-2023
(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
.
RE: Web UI via HTTPS - bump_here - 12-31-2023
(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
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.