3.51 - Suggestion on how to improve new gui security certificate issue

At the GUI V2 launch announcement Page 43 we read:

To access Remote Console on LAN over https, accepting a browser warning about a non-valid
certificate is required. There is (unfortunately) no way around this.

Some firewalls or company policies with packet inspection reject pages with certificates like this completely and it is not possible to use it at all. To solve this matter easily, there is a FOSS project of Peter Eckersley. Unfortunately he suffered with colon cancer and died only two years ago. Fortunately his project is still alive, maintained by many of his fellowes and offers free domain validated certificates with a lifetime up to 90 days. In this time any online connection might update the signed certificate by using the ACMEv2 protocol for free automated certificate renewal. Today, there are millions of unexpired certificates active for IoT devices. Would appreciate to see a URL Domain setup possiblitiy in Venus for obtaining X509 by ACME client. Here is how to implement:

I’d like to second this. This would be a nice way to have a free automatically renewed certificate that would NOT cause this problem. All it needs is a tiny bit of automation during the install and after that it would just work as long as you had internet connectivity but if you don’t have that, you probably don’t need https at all.

Hi both, we’d like this as well - and maybe can look at this at some point but for now have too little capacity for this and/or too many other prios.

ps. anyone is (very) welcome to make this work on their GX and in that way prove that this is solvable + show how its done.

Do you have a document that outlines how you want it to work? For example are you running nginx as proxy on the frontend or apache, or what? Getting it running is pretty trivial but knowing how you want the product to work is important. Is the current setup the one you want or the one you have?

Hi Mark,

yes we’re happy with the current setup. Its indeed nginx.

Further reading here: Home · victronenergy/venus Wiki · GitHub, including root access.

Immediately ran into the issue of a domain name being needed for a Let’s Encrypt certificate. They don’t issue them for IP Addresses and getting a domain name for the device means setting up a DNS server that interfaces with starlink and attempts local resolution before the wider internet is queried. This will make this a lot more difficult for most of the public.

There is no equivalent of /etc/hosts for cell phones without Root access or some type of DNS Override app on the phone (honestly, I haven’t found an app for the iphone that lets me make my own entries) so this might not be all that doable. I’ll have to think on it some more. IP based TLS certs would be best but those are not in the cards with Let’s Encrypt

Hey @boatcoder :+1::+1: for trying!

What about using venus.local?

That works on all platforms, maybe even including Android. I’ve heard that it works on Android since Android 12.

https://issuetracker.google.com/issues/140786115?pli=1

Actually venus.local did work for me on the boat. I’m going to need to dig into how we prove ownership for the acme app from Let’s Encrypt. Normally they put a file in place and then fetch that page, but they won’t be able to do that behind a firewall. Good thinking.

.local is not a valid TLD, it’s a special use domain for internal rather than public networks. No certificate authority will sign a certificate for that domain.

LetsEncrypt is only really an option if you have a registered domain name that you have control of.

There aren’t really any non-complex ways to get a trusted certificate onto these devices.

Trusted certs are really for public, commercial sites to provide some degree of confidence. IOT devices rarely have anything beyond a self-signed cert.

Plenty of orgs using internal CAs to sign certs for all sorts of kit.

Can be done at home with a few Openssl commands but quite a lot to understand to get to that point.