peekay Posted April 29, 2023 Posted April 29, 2023 I keep coming up with errors on my iPad and Linux/Firefox desktop trying to run the Polygot_v3 dashboard that really appear to be issues with the self-signed certificate. Are there any guides or known problems with running certbot on the Polisy with DNS verification? My Polisy has a proper FQDN (only accessible via VPN). Is the certificate used the one in /etc/ssl, or are there multiple locations that need to be linked?
bpwwer Posted April 29, 2023 Posted April 29, 2023 For PG3, I believe it is still possible to use your own certificate. The certificates would go in /var/polyglot/pg3/ssl/custom and you'd have to change the /usr/local/etc/rc.d/pg3 startup to tell PG3 to use the custom certificates. For PG3x, it is not possible as changing the certificates will break all communication between PG3x and node servers (and other components on the system). 1
Javi Posted April 29, 2023 Posted April 29, 2023 Try using http instead of https for local or vpn connections, this should avoid cert validation.
peekay Posted April 29, 2023 Author Posted April 29, 2023 18 minutes ago, Javi said: Try using http instead of https for local or vpn connections, this should avoid cert validation. That doesn't work because many browsers force https and fail silently or with obscure errors.
peekay Posted April 29, 2023 Author Posted April 29, 2023 1 hour ago, bpwwer said: For PG3, I believe it is still possible to use your own certificate. The certificates would go in /var/polyglot/pg3/ssl/custom and you'd have to change the /usr/local/etc/rc.d/pg3 startup to tell PG3 to use the custom certificates. That should be easy enough. 1 hour ago, bpwwer said: For PG3x, it is not possible as changing the certificates will break all communication between PG3x and node servers (and other components on the system). Wow, that is a major design flaw! Requiring communications via an insecure communications method?!
bpwwer Posted April 29, 2023 Posted April 29, 2023 2 hours ago, peekay said: Wow, that is a major design flaw! Requiring communications via an insecure communications method?! Not really. UDI creates the certificates that are used by all the components to enable encrypted and signed communication. There's nothing "insecure" about that. The problem is that browsers have no way to trust non-public servers at least not in a way that's easy for user's to configure. Servers like PG3, don't typically have a public IP/DNS address. PG3(x) has no way to get a certificate from a signing authority. The only option is to use a self signed certificate**. If you don't trust the certificate signed by UDI, you probably shouldn't be using UDI controllers. Currently, the browser based UI is only designed to support local connections to PG3(x). You can use SSL encryption for this (but you have to tell the browser to accept the self signed certificate) or you can use unencrypted connections. It's your choice. I would not recommend trying to use the browser UI remotely unless you're connecting over a secure VPN. We are working on providing UI remote access to PG3x. The connection will be routed from a secure internet visible server to PG3x over a private secure connection (similar to VPN). ** Yes, it is possible to configure a Polisy/eisy to have a public DNS address and get valid certificates generated for it. However, doing so is probably outside the scope of what most users can do. With PG3, you can do that because the only thing that makes use of the certificate is the browser UI or UD Mobile. And in theory, you could do the same for PG3x, except that all the internal communication is now SSL encrypted based on the certificates that UDI creates. So you'd have to replace all them, including generating new certificates for each node server. So while it may be possible, it's not really practical. ** And also, it is possible to set up a system where PG3(x) gets a public DNS and certificates from an authority, but doing that is non-trivial and also not free. (Plex for example, does this). But UDI would probably need to require a more expensive portal license to cover the costs.
Javi Posted April 29, 2023 Posted April 29, 2023 3 hours ago, peekay said: That doesn't work because many browsers force https and fail silently or with obscure errors. You referenced iPad, Apple disables App Transport Security In iOS 10 and macOS 10.12 and later for local loads. https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsallowslocalnetworking
peekay Posted April 29, 2023 Author Posted April 29, 2023 2 hours ago, Javi said: You referenced iPad, Apple disables App Transport Security In iOS 10 and macOS 10.12 and later for local loads. https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsallowslocalnetworking That doesn't work with a FQDN or from a separate VLAN. As is common security practice, my IoT equipment is in a dedicated VLAN (actually a few different ones), and communications between VLANs controlled by the firewall.
peekay Posted April 29, 2023 Author Posted April 29, 2023 4 hours ago, bpwwer said: Not really. UDI creates the certificates that are used by all the components to enable encrypted and signed communication. There's nothing "insecure" about that. The problem is that browsers have no way to trust non-public servers at least not in a way that's easy for user's to configure. Servers like PG3, don't typically have a public IP/DNS address. PG3(x) has no way to get a certificate from a signing authority. The only option is to use a self signed certificate**. If you don't trust the certificate signed by UDI, you probably shouldn't be using UDI controllers. If the certificates are signed by UDI then it is not that hard to allow a FQDN (xxxxxx.isy.io or something) that resolves to a private IP address and properly uses PKI. 3 hours ago, bpwwer said: ** Yes, it is possible to configure a Polisy/eisy to have a public DNS address and get valid certificates generated for it. However, doing so is probably outside the scope of what most users can do. You don't have to have a server publicly resolvable to use certbot, you just use DNS txt file authentication. It is a solved problem. Sure, it might not be for everyone, but it is a completely valid approach. Compared to the complexity of working with the admin console and all its quirks, setting up certbot really is trivial. I'm starting to feel like the complexity of managing links directly for Insteon is also worth the pain compared to design decisions that have stuck around with UDI for over a decade that still limit usability for me today.
Michel Kohanim Posted May 3, 2023 Posted May 3, 2023 On 4/29/2023 at 4:30 PM, peekay said: If the certificates are signed by UDI then it is not that hard to allow a FQDN (xxxxxx.isy.io or something) that resolves to a private IP address and properly uses PKI. I think you are confusing two things: certificates to be used between node servers and PG3x and the https certificate for the web server. In PG3x, every node server has its own certificate, unix user, and mqtt channel. This way, no crosstalk is ever possible at any level. Certificates are regenerated every time udx service starts (or the unit reboots). Regarding having a certificate for the webserver part of PG3, I don't see any problem with supporting it. It might be a little difficult considering that the UI uses mqtt over websockets but definitely doable. On 4/29/2023 at 4:30 PM, peekay said: I'm starting to feel like the complexity of managing links directly for Insteon is also worth the pain compared to design decisions that have stuck around with UDI for over a decade that still limit usability for me today. I am not sure what to suggest here. I guess we can never make everyone happy. Thankfully, there are other options so I am sure an expert, such as yourself, would be able to figure out the best option. With kind regards, Michel 2
Solution brians Posted May 3, 2023 Solution Posted May 3, 2023 On 4/29/2023 at 4:30 PM, peekay said: If the certificates are signed by UDI then it is not that hard to allow a FQDN (xxxxxx.isy.io or something) that resolves to a private IP address and properly uses PKI. You don't have to have a server publicly resolvable to use certbot, you just use DNS txt file authentication. It is a solved problem. Sure, it might not be for everyone, but it is a completely valid approach. Compared to the complexity of working with the admin console and all its quirks, setting up certbot really is trivial. I'm starting to feel like the complexity of managing links directly for Insteon is also worth the pain compared to design decisions that have stuck around with UDI for over a decade that still limit usability for me today. I use a pfSense router with Acme Certificates (letsencrypt), and HAProxy. I use to access things like Home Assistant, OpenSprinkler remotely, but can also be used locally with the FQDN... also setup Dynamic DNS via GoDaddy. I never had issue connecting to local IP address of PG3, but I rarely do and do not see a reason why I would need to connect to it often anyways - it's sort of set and forget and not really much to look at in there. Are these errors you are getting preventing you from accessing the site, or is it just an insecure site warning that you can click through?
peekay Posted May 3, 2023 Author Posted May 3, 2023 1 hour ago, brians said: Are these errors you are getting preventing you from accessing the site, or is it just an insecure site warning that you can click through? The browser actually blocks the connection (silently) after clicking "trust anyway" on either the iPad (Safari) or Linux (firefox). Thanks for confirmation it works.
Recommended Posts