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.
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.
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:
generate a unique private key/public key pair
generate a CSR using the private key
log on to the lutron device management server
get the lutron device management server to sign the CSR. This generates an "App Certificate" and a "remote certificate".
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...
getting a private/public key pair requires crypto functions. HE does not (yet?) support crypto functions
the communication to the bridge requires the ability to do an SSH connection with the bridge. HE does not support SSH. HE does support Telnet, so SSL over telnet could work, but SSL requires crypto... See item 1.
direct control via the Lutron cloud is not publicly documented, and so far nobody has reverse engineered it. The Documentation is available from Lutron if you are a Lutron partner. Not a viable solution.
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.
