SSL Certificate and New App


#1

I am trying to write an app to integrate the new Ubiquity Protect NVR.

It uses https but I am getting a security error.

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

how do I get past this?


#2

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.

Tagging: @bravenel and @mike.maxwell as they should be able to confirm that.


#3

I assume the end ubiquity device doesn't have a signed cert? That is the error there. So it would have to be resolved on the ubiquity side.


#4

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.


#5

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.


#6

Ahh.. didn't know that. Hope you will get protect working.


#7

I might, If I ever get the time to sit down and focus on it. lol


#8

@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.

-Jeremy


#9

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.


#10

@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. :smiley:


#11

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


#12

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.


#13

What thread is that? Last I knew there was no API for protect.


#14

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.


Security, ssl, and certificates
#15

It is not published but a few community members are figuring it out.


#16

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"}


#17

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.


#18

Ahhh, ok. I was specifying a port. Thanks!


#19

I believe you need to specify a port for the other commands.


#20

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.