I have an IP device with a web service that I’m trying to get to (actually, it’s on my LAN and I’m forwarding a port), and the service is accessible via HTTPS. I’m trying to send an httpGet request; however, the console gives an error and reads “peer not authenticated”. The IP device is using a self-signed certificate. Is there currently a way to trust self-signed certificates using httpGet with the https protocol? If so, can someone please post a code sample?

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

@snoopbuild – So I’ve been looking into this since I saw your post yesterday. The answer is exactly what you proposed: allowing SmartThings developers to disable SSL validation checking on a per request basis. Support for that is on our backlog - but I don’t think it’s been prioritized yet. But as you state, it is something that we’ll need to support when general support for LAN-connected IP devices becomes available.