Security, ssl, and certificates

I approach SSL/security with my HE Hub the same way I do will all servers/applications on my network. I doubt everyone will go to the trouble to set up an enterprise grade network at their house, but I'm a cloud/devops engineer by trade.

Everything is behind a proxy or load balancer that terminates SSL using signed/trusted certificates. Letsencrypt makes life easy when it comes to certs; they also released wildcard certs not too long ago which makes things even easier.
If you don't have anything like this set up, then self signed certs are probably more than sufficient.

On top of this, I keep everything IOT on it's own network/VLAN and keep that network locked down on the firewall. This means that even if you are on the WIFI or LAN network, you can't see any of the traffic from the HUB.

Securing your Hub with SSL prevents someone that's gained access to your network from seeing login credentials when your browser authenticates. It also ensures all web traffic is secured. This is important, as others have mentioned, because lock codes and other sensitive information is contained on certain pages.

That being said, you can accomplish all this fairly easily using your default modem/router, place it in passthrough mode, and connect it to a pfSense appliance to use as your router/firewall. If you don't have a decent firewall, it's probably not worth using anything other than a self signed cert IMHO.

1 Like

They could also do the same thing sitting outside your house. And they wouldn't have to hack anything to do it either.

1 Like

Right, but this approach doesn't require the whole "why has some shady lookin dude been staring at me with binoculars all day every day this week?" part. Passive data logging sight unseen will do.

Yeah, cause no one was able to learn your routine before Smart Lights came around.

As with computers and identity theft. As technology advances, so do the ways of doing old things.

How is learning when my smart lights go on and off going to give anyone any information that would be worth something? You do realize that there are much, MUCH easier ways that people get their identity stolen. There's a reason that phishing attacks still go on. THEY WORK. No one is going to hack into your smart lights so they can break into your home to steal your identity. You need to take off the tin foil hat my friend.

1 Like

Hmm...perhaps I'm not getting my meaning across. In any case, there isn't a need to be defensive. We're not saying that you have to deploy TLS certificates, we're just saying that we want to.

This Thread has been going on for 6 months, roughly. With 9 participants and 9 likes. Let's imagine that this is half the people interested in a solution, that would get their own Certs and deploy them and the root properly, anytime in the first 3 attempts.

You have no idea how much I hope that under 20 people is 0.1% of the Hubitat user base. The solution to this problem for all 20 people is quite large for a tiny development team.

Despite the fact that I could USE this solution, and would, I sincerely hope it is far down the priority list. I know that Hubitat recognizes the need, but the solution will just burn through too many hours with the solutions available... (none)

A solution that applies to 100% of the manufactured hubs is needed. A means to generate and install a unique cert on every hub either during manufacturing or as part of the registration process.. a means to invalidate and reacquire a cert, which again points back to the registration'ish process... with a root CA that is known to all browsers... Extensible to be replaced with self-signed CA and cert.

Solving this for 20 people, vs solved for ALL Hubitat customers, should be the goal. my opinion.


Well I don't really need all of that, I just want to use my private root CA, in fact I would specifically prefer it not be a public root CA. I'm sure when it generates its own self-signed certificate and private key pair, it stores it somewhere. All I'm really asking is to be able to replace that with my own.

1 Like

The paranoid amongst us put our hubs on a separate (non wireless accessible) vlan and use enterprise grade hardware to configure and secure this :slight_smile:
However, I do understand your request to use your own ca auth.
But has been mentioned before, I would prefer that HE limited resources be employed elswhere. :slight_smile:



Well, there's paranoia and then there's pragmatism :slight_smile: To me it's basically economics, namely an opportunity cost. If you already have the knowledge and equipment, then the opportunity cost is low enough to make the benefit well worth it :slight_smile: I didn't need 10 motion sensors, but the cost difference between 5 and 10 was basically nil when I bought mine, so now my house has 10 motion sensors installed :slight_smile:

I would be happy with being able to change the port to access HE from the internet. Ex. my_ip_address:33443
I use a stand alone firewall that I would like to isolate HE access to when I am away with out the need for a cloud.

That's off topic for this discussion. But the proper way to access HE externally is NOT to do NAT port forwarding, but to get a router which supports a VPN connection.


Actually my firewall does support VPN. I disagree. VPN is to connect to an encrypted private network. I only need to connect to this device of which port forwarding would work perfectly. I think I could work around the HE limitation by forwarding an obscure port to Hubitats 443 through my firewall's inbound traffic. Not sure why we can't update the listening port for Hubitats web server and to disable http port 80 altogether.

Using a random port is security by obsecurity and the reality of that is that is simply not security. Fortunately you mention port 443 which i think means you also would want to setup SSL/TLS with a certificate that you would need to maintain. Most people won't do that. Even if they do because we dont have full access to manage the HTTP server we can't ensure it is hardened/setup for vulnerabilities or ensure it is updated to prevent new ones as they come out. Lastly even if we hardened the HTTP server the app interface could be subject to vulnerabilities.

Probably the biggest problem is that the folks at hubitat have said more then once it isn't a hardened device and should never be placed directly on the internet.

The reason the VPN is the prefered method of security is because the premise of the VPN is as you stated to secure your remote device back to your home private network. Then Hubitat never is exposed to the rest of the world for people to try to get through.

If you absolutely insist on putting it out there and don't care about the risk, probably the best method if you dont use a VPN would be to use a hardened reverse proxy like Nginx with a long secure login password in Hubitat. Atleast then you can ensure it is using SSL and not worry directly about the webserver on Hubitat. That is a best of bad ideas though.


Ok you sold me I will set up VPN access. Thanks Mikes.

1 Like

Most bowsers are insisting to go HTTPS otherwise will give you a warning the connection is not Secure. This are not HE issues.
Also, if you want to remote your HE, most likely you will want your data secure. If you have a lock, will not be nice if someone open your door or drapes in the middle of the night.
If you are only local: not a big deal.
Perhaps you now that IPV6 is here.... and extra risk. Some routers allow you to connect directly to your units, firewall free!!!

As someone who has worked in computer security, this thread disturbs me greatly. Yes, of course you should not allow access to your Hubitat Evolution directly from the Internet, and yes, a VPN is the right way to provide access. But that's not enough. You also have to ensure that traffic over your LAN to/from the Hubitat Evolution is encrypted. Why? Even on a secure home network it's very easy to get eavesdroppers. Just consider a guest asking to connect to your WiFi (or worse, one of your kids' friends). Assuming you know them, they aren't likely to do anything malicious, but who's to know what is running on their device. It may not happen immediately, but at some point you are likely to have some malicious code running inside your network. And yes, even if you have them connect to a guest wifi, it's all too easy to have misconfigured rules that allow the malicious code to sniff packets going to your Hubitat Evolution. And that is gold, since no HTTPS means no password encryption. And as soon as that is captured, they have full control of your house, including your locks.

There are a set of mitigations that you can apply to the scenario I outlined above, but you will end up making impossible trade-offs, e.g., requiring a local VPN to access the Hubitat Evolution so that the IOT network can truly be isolated, is a usability nightmare - sorry dear, just give me a second to get the VPN connection so I can control the lights, etc.

And doing so gets increasingly more complex, fragile, and further away from the mainstream.

So, please, for the love of everything you hold dear, add HTTPS/SSL support, even if you just use a self-signed certificate - most browsers won't complain about this too much if it's on your local network.

1 Like

@Hubitat_Staff .... Any update on this?.. also the built in hubitat cert expired on Apr 2021 !
I think if hubitat cannot update the certificates, then atleast they should allow users to use their own (domain/ self signed certificates ).. it is definitely better than expired certificates !!

When you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

Site 192.168.xx.xx
Certificate CN
Certificate Authority Hubitat Elevation
Certificate Validity Not Before: Jan 10 21:29:33 2019 GMT

Not After: Apr 14 21:29:33 2021 GMT|