It looks like something support will have to handle in an update to the hub itself. From reading the article below, it looks like HE would have to support importing certs from the admin interface. I'm not sure what the level of effort would be on the developer's side of things.
I know Smartthings community has this working but with HTTP only. It was a while back possible they have it with https now. The code is in groovy and doesn't sound like you will have problem porting it. Have a look.
UniFi Video and UniFi Protect are 2 different animals. I wrote drivers and an app for UniFi Video (NVR) to work with HE but those same drivers will not work with UniFi Protect, at all.
@patrick I'm pretty sure the Ubiquity device in this case would be on a private network with a private IP and hostname, right? If so: You can't get certs for a private hostname signed by a public CA. Before a CA can sign a certificate they have to verify the identity of the hostname being applied to use on the certificate. If it's not a public hostname that can be verified there's no way to get a signed certificate for it.
The typical method to connect to an SSL based service that's hosted locally on your network is to do an "internal" sign (Or self sign) which would require adding trusted keys to the Hubitat "truststore" (aka "cacerts" in Java). Internal signing is most common: With an internal sign it's not signed by a "public" CA but rather by a private one, like perhaps Ubiquity themselves internally signs it. However Ubiquity's CA cert is not going to be in the list of CAs trusted by Hubitat, so there needs to be a way to import additional "trusted" CAs into HEs truststore/cacerts database.
So this is absolutely a problem that would likely need to be solved on the HE side as we would need a way to add trusted signing keys to the HE trust store. Alternatively you could add a feature in HE that allows HE to connect to untrusted SSL servers, but that would be a big security risk.
The only way this could be solved on the Ubiquity side would be if they somehow managed to use a public hostname on the private network and sign the SSL cert with that public hostname and use some sort of internal DNS server to map that public hostname into a private IP address. Not impossible but not exactly easy.
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.
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.
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.
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.
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).
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.