Yup, this is the exact problem in reverse connecting to hubitat over SSL as well. SSL certs on private IP networks is not possible. Overriding this is a security issue to allow self signed certs.
It isn't an easy thing to fix especially for a consumer, involves custom DNS names, letsencrypt certs, etc.
Meanwhile browsers are blocking connections and forcing everything to SSL.
The best option for a local connection on a local lan, is to use http and avoid the cert issue all together.
@patrick I know this was suggested.. but you could offer a button on Hub Details that displays the self signed Hubitat root cert. That allows ME to fight with my equipment to make it functional. Doesn't help everyone, but it helps 100% of everyone that knows what to do with it. 
Hi @patrick
I work in at an enterprise software software and I deal with this issue with my customers needing signed certs for private hosts on a daily basis. It's really not that hard to solve. Most software products offer a way to import trusted keys into the "truststore" or "cacerts". That's all that would be needed here. That would allow me to either personally sign a certificate myself, or have it signed by a private CA that I trust and then simply add that trusted CA's key to the truststore. As long as I know I can trust that particular CA when I import the key it's not a security risk.
Same thing with the reverse issue on connecting to HE over SSL: If HE would simply let me import my own certificates instead of using the certs that ship with HE, that again would solve the problem. (And be far more secure since, as it stands, I really have no idea who else holds the private key used for that cert) Being able to provide my own keys, and configure what keys to "trust" is by far the most secure solution, and is the industry standard for every piece of SSL enabled software I've worked with.
-Jeremy
There is a thread on Ubiquiti's forum where a few people have figured out some key APIs. So I was trying to modify your Unifi NVR app to work with Protect.
If I try to connect via http the Ubiquiti server pushes it over the https.
What thread is that? Last I knew there was no API for protect.
Yeah, we are looking at this as an option, but big difference between enterprise software and consumer HA. Most aren't going to know where to begin to personally sign a cert, make a private CA or import keys properly.
Most interesting model is how Plex did things... We will see what we can do. In the mean time, I recommend sticking with the http side of the local web UI until we work out these details. For those that need SSL for local, going to have to wait for some fixes to emerge as we deal with a changing consumer technology space.
It is not published but a few community members are figuring it out.
I took a quick look at that thread. Tried a few things with curl and I'm getting nothing but errors asking for username and password, even on GET's that shouldn't require it (according to the thread).
{"error":"Unauthorized","type":"AuthenticationError"}
If you use chrome you can get a response from this:
https://192.168.17.2/api/ump/info
However, on HE I cannot even get that due to the SSL error.
Ahhh, ok. I was specifying a port. Thanks!
I believe you need to specify a port for the other commands.
I messed around a bit more and got to the point where I can get an accessKey using some bash scripting to test. I can't seem to use that key yet though.
I did also find several hits when searching for "groovy https ignore certificate". I'm not really up to snuff on Groovy but I'll try if/when my schedule allows.
I'm new to the product and this forum, and could not agree more with jeremy.akers sentiments. I am a security professional and regularly make use of IPSec VPN to access my local network. My network and access security posture is based on my private PKI environment, where all certs utilized are generated through my internal CA. This is not for everyone, but when I can't install one of my own certs I generally place the device behind reverse-proxy. It would make it easier to allow users to deploy their own self-signed certs. As stated by others, this is done all the time without weakening the device security profile. To ensure Hubitat cert/key pair security a factory-reset option could be added that regenerates a new cert/key pair each time the device is reset. But there need to be a self-signed cert/CA option.
Cheers,
Darwin
@patrick, any update on this?
I'm working on a device handler that communicates with my local OpenWRT router which uses a self-signed SSL Cert and I've run into the same issue.
I totally agree with the comments of @jeremy.akers and @darwin1357 above. We desperately need functionality to import our own private (self-signed) certificates into Hubitat.
Suggesting that we should fall back to using non-secure http connections is not really acceptable and not even feasible in many cases.
There is no update, It is still on our list of things to do, but has not been implemented.
Glad it's being considered at least.
Allowing import through the admin interface and the ability to specify a specific self-signed certificate to use for an HTTPS connection would open up integration options for a few devices with closed APIs. The non-pro Lutron Caseta hub being my number one target, Home Assistant has this solved but it requires this feature if I understand their implementation correctly.
Even once the ability to add certs to HE is implemented, that will not help to develop a native HE driver for the non-pro bridge.
The non-pro must use the "LEAP" protocol. In order to use this protocol, a client must:
Once that is done, the client then communicates directly with the bridge using an SSH connection with the private keyfile as the SSL encryption key, the App certificate as the client certificate and the remote certificate as the CA Certificate chain.
So... This issues are...
Home Assistant's component for Lutron Caseta is based on pylutron-caseta which includes this script to generate the key pair. That can be run on a separate PC so I wouldn't expect all that functionality from Hubitat, just the UX to import and manage certs after I've generated them.
That leaves the SSL connection as you pointed out (I thought it was HTTPS to the bridge but was mistaken, it's a TLS socket). We recently got raw sockets so maybe we'll get lucky and the ability to build and specify an SSL context can also be exposed from the underlying Java libraries as part of that feature in the future.
Bumping again for an update.. Thanks Chuck!
it would be great if we could import our own cert
Download the Hubitat app
