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?
Thanks!
@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.
Any progress on this? Looking to implement something similar and need to use self-signed certs.
Any progress on this? Have a baby on the way and would love to integrate my webcam with SmartThings.
What about allowing users to add root certs we trust? Disabling SSL validation opens you up to man-in-the-middle attacks, which I’m not super-keen on.
I’m trying to built a smart app that would communicate with and HTTPS service using self-signed certs. Is there a way to do this yet?
Has there been any progress on this?
I too need this to allow me to try and connect to my Honeywell Evohome 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 @ line 79
Looks like we need the ability to call the ignoreSSLIssues() method on the underlying HttpBuilder (I assume that’s what it’s using under the covers)
Martin
Hi there kids
I am trying to do this. Has there been any progress?
I am on the same wagon here : https://community.smartthings.com/t/httpget-and-shields-io/138708
Hey Dan
It’s been a long time - any movement on this?
Same here. Only https available.