@dlieberman, You’ve mentioned self-signed certificate in some other forum posts, so I’d like to get your input on this:
Is it possible to send an httpGet request via HTTPS to an endpoint using a self-signed certificate?
Support for this is very important, simply because, almost no device manufacturer is going to provide publicly trusted certs for devices to be installed and made accessible on local customer networks. If mean, if Cisco doesn’t provide publicly signed certs for their ASA routers/firewalls, Netgear doesn’t for their ProSafe routers/firewalls, Synology doesn’t for their NAS devices, and Foscam doesn’t for their IP cams, then self-signed certs (as opposed to publicly signed and trusted certs) will continue to be the norm for customer-purchased and installed network devices, and therefore, sending an httpGet to an HTTPS endpoint will need to be supported.
I do know that Microsoft thought it was important enough in their ASP.NET platform to include the ability to override SSL validation on a per HttpWebRequest basis, which, in my opinion, is the best way to handle self-signed certs. (The previous workaround with ASP.NET was to pretty much disable all SSL validation, which would introduce security issues. But Microsoft’s answer to that with their ASP.NET 4.5 release was to allow SSL validation to be overridden on an as-needed basis per HttpWebRequest, as user2117074 says (and links to) in this discussion: http://stackoverflow.com/questions/526711/using-a-self-signed-certificate-with-nets-httpwebrequest-response.)
If network devices with HTTPS APIs continue to follow the trend of having self-signed certs provided by the device manufacturers, then the HTTPGet method provided to SmartThings developers should support HTTPS communication to endpoints having self-signed certs, especially if support for LAN IP communication via SmartThings hub is coming down the pike. Allowing SSL validation overrides per httpGet requests seems to be the best way to go.