MWareman

This... I actually bought the Elk io expander so I can start replacing several iolincs for more critical control (I have a water shutoff valve, for instance). Also, newer Insteon devices won't respond to the perceived reception of an 'All On' signal anymore, but that doesn't help those of us with extensive number of older devices. If only Smarthome allowed reflashing firmware....

Yes. Don't use an iolinc for garage door control. I use an input and output on my Elk, with the added bonus that the sensor triggers my alarm entry delay.

I don't think it's published - or necessary to know. UDI wrote its own real time OS for its custom designed hardware. It's like asking the CPU and ram of a clock radio - it doesn't matter. It just does its job very well.

Good to hear! Thanks for the feedback. I look forward to being able to test in these areas of the product. Michael.

OK, thanks. I'll be content that it's on the list - even if fairly low. To others: the best way around this is to run a Raspberry PI. Either with Apache/PHP or one of the various Python solutions on here you can create an inbound proxy to the REST API that the Maker IFTTT channel can call. I'm using PHP and have posted my script above. You can use any paid certificate on the rpi as long as its installed correctly.

OK, thanks. So this is another deviation from the requirements of TLS 1.2. Normally, only the root need be installed. It's up to the server to send its own cert and any needed intermediaries ultimately chaining to a root that's in the ISY. By not implementing this (required) ability, we have to manage not only the roots, but also the intermediaries directly in the ISY. Given that intermediaries change fairly often with most CAs, this is entirely impractical. That being said, asking people to deselect 'verify' to work around this creates a vulnerability - and this alone should cause the issue to raise above 'low' priority. Would it not be better to advise people to simply import the Globalsign root and RapidSSL intermediate root into their ISY with the Dashboard and leave 'verify' checked? (Especially if they've previously been successfully using the ISY with 'verify' checked in the client). Michael.

So, with the global client side 'Verify' checked, all connections to servers that have a chained certificate will fail because ISY doesn't process the chain at all - client or server side. The user would have to import the root AND intermediate certs for all services they need to connect to if they needed 'Verify' checked. How do customers using their ISY for power integration also use the portal, if global 'verify' must be unchecked for the ISYPortal to work, but I suspect this would violate policy for OpenADR? How will processing change with connection based policies? Will this include the processing of a chain? As I mentioned, by needing 'Verify' to be unchecked it leaves open a vulnerability, as any self-signed cert with the common name 'my.isy.io' on a proxy, and a DNS cache poisoning attack can be combined to compromise the encrypted communications between the ISY and the ISYPortal. I feel that on its own justifies higher than a 'low' priority fix. Michael.

I don't really think high priced certs are feasible for most people - so I'm not sure the value testing this option. Thanks for the offer anyway! I did just edit the post above referencing another post. Can you confirm why 'Verify' needs to be unchecked in the TLS client to work with ISYPortal? Thanks! Michael.

OK sounds good. I can see how having the option to reject intermediaries would assist in certain scenarios - specifically in the role of a client. But in the role of a server, it provides zero benefit. I understand that the decision was probably a while ago, but in the role of a server not allowing intermediaries as an option actually makes the product non-compliant with the TLS 1.2 specification. As a work around, do you have a source for single-root retail certificates at a price point somewhat friendly to non enterprise users? Michael. Edit. Saw this post: http://forum.universal-devices.com/index.php?/topic/17212-ISY-Portal-Says-Device-Offline&do=findComment&comment=155291 What is the reason 'Verify' needs to be unchecked? Is it because ISYPortal uses a chained certificate, but ISY cannot verify a chain in the client role either? Leaving 'Verify' unchecked leaves the connection open to man in the middle attack scenarios. It would definitely make the case for making this a higher priority then 'Low' - personally I would place this in the category of 'vulnerability'. Either that - or you should get a single root cert for my.isy.io so we don't have to unchecked 'Verify' for the portal to work.

I'd be interested to hear more about the reason for choosing to exclude support for intermediaries. In the TLS world, not supporting it actually prevents the ISY from being able to be verified by a strict RFC compliant client, such as IFTTT, when a chained certificate is in use. It seems a counter-intuitive choice to make. UDIs own Portal (https://my.isy.io) uses a RapidSSL certificate, where RapidSSL is the intermediate to a Geotrust root. The portal correctly handles the TLS connection. Why support it there yet not on the ISY? As asked above, this would be a non-issue if retail certificates were available without intermediate certs. That's not been the case now for at least a couple of years - but the ISY manual continues to advise customers to purchase a certificate to use with the ISY, and the result is that the certificate cannot be verified by remote API's. This is not only the case with IFTTT. All APIs I've played with verify the full trust, and this failed when the server does not send the full chain. Do you have a suggestion where, at retail, certificates can be purchased with a single root for use in the ISY?

Unfortunately, by not handling an intermediate certificate, the ISY fails to adhere to the TLS standard RFC5426. In particular: http://tools.ietf.org/html/rfc5246#section-7.3 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake and 7.4.2. Server Certificate When this message will be sent: The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message. Meaning of this message: This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions. Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. So, client connects and requests SSL Server sends back a message containing a 'Certificate' to convey 'the server's certificate chain to the client.' Please pay attention to the use of 'MUST' in the standard.. The certificates MUST be sent by the server to the client in sequence, with the senders certificate first, followed by the next certificate that verifies the device certificate and so on until a root. The server actually sends the root as well (as evidenced with the way Apache does it). The signature of the root is able to be verified by the client - and so the entire chain is trusted. Without the intermediate and root being sent by the ISY - a strict RFC browser can never trust the certificate. Why? Well - if the client cannot verify the certificate of the signing CA then the connection should be refused. Since the ISY cert was issued by the intermediary - but the client only has the root - the chain of trust is broken. Michel: PLEASE add this! It's terribly important - especially now that 90% of CAs (even big guys like Verisign) issue from subordinates. It fundamentally makes server side SSL impractical on the ISY without it - and it's a violation of the RFC to support TLS and not support the proper sending of the certificate chain. The only reason I haven't hit this in the past is I've proxied access to my ISY. Michael.

Unfortunately, that's not how the TLS spec works. Intermediate certs must be returned by the server for the subordinate cert to be trusted at all. As we all know, its not possible to install an intermediate on IFTTT.

I am using openssl on my Ubuntu host. I also have a question in to Michel on the correct way to handle intermediate certificates. Michael.

This is what I've tried.... I created a .pem cert from the private key, certificate public key and the chain key with the following command: openssl pkcs12 -export -out cert.new.pfx -inkey cert.key -in cert.pem -certfile chain.pem I verified the pem bundle with the following command: openssl pkcs12 -info -in cert.new.pfx ..and it definitely contains the cert public key, cert private key and the chain public key. All good. I used the dashboard to import the pfx bundle... it accepts it and ISY reboots. I use Windows to browse UDAJAX over SSL - looks good. I used openssl to test the installation: openssl s_client -connect 192.168.1.20:5228 I got the following response: CONNECTED(00000003) depth=0 OU = Domain Control Validated, CN = *.domain.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 OU = Domain Control Validated, CN = *.domain.com verify error:num=27:certificate not trusted verify return:1 depth=0 OU = Domain Control Validated, CN = *.domain.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.domain.com i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 --- Server certificate -----BEGIN CERTIFICATE----- <cert blob removed> -----END CERTIFICATE----- subject=/OU=Domain Control Validated/CN=*.domain.com issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 --- No client certificate CA names sent --- SSL handshake has read 1449 bytes and written 655 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA256 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE <SSL Session block removed> Note the 'Certificate chain' block - it ONLY contains the one certificate... This same certificate on my Apache host (properly installed) looks like this: CONNECTED(00000003) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.domain.com i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA --- Server certificate -----BEGIN CERTIFICATE----- <certificate blob removed> -----END CERTIFICATE----- subject=/OU=Domain Control Validated/CN=*.domain.com issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 --- No client certificate CA names sent --- SSL handshake has read 4002 bytes and written 479 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE <SSL Session block removed> Note that not only is the issued cert returned - but so is the intermediate AND root. This is what needs to happen for IFTTT to properly trust the endpoint. I further used SSLLabs to test - it shows that the chain cert was NOT sent by ISY - so the chain is incomplete. You cannot use SSLLabs if your port is anything other than 443 - in this case you can try https://www.sslshopper.com/ssl-checker.html. It also shows a broken trust chain when the certificate is served from ISY. At this point - it's a support call to UDI I'm afraid. ISY seems to be NOT sending the intermediate and root certificate - which is required for SSL to succeed to IFTTT. Michael.

You will probably need to add the intermediate as a CA using the dashboard. Normally, the intermediate needs to be returned with the signed public key during an SSL negotiation. I'm working on this myself - its likely that we need to put the root, intermediate and signed cert into one file and import that as the certificate bundle. As I've mentioned, I have SSL on my Apache (Ubuntu) host and use that to proxy to my ISY. It might take a contact with support to find out the correct way to do this directly on the ISY, especially since they use AlphaSSL certs themselves on their Portal!

If there is suspicion that the device has a static IP that's not valid for the current network, you can always connect the USB port to a computer and use a serial terminal to access the console. From there, you should be able to find the current network settings (IP), and change the device from static to dhcp if necessary.

Mobilinc Connect is just another connection profile. It can sit with profiles for ISYPortal and direct to ISY as well... At least on Android it can..

To use Mobilinc with ISY Portal.... Logon to ISY Portal and get the Admin Console URL (the one with /desc at the end). Use device type ISY - not Mobilinc connect. In Mobilinc, blank out the HTTP URL. You won't use it. Place the Admin Console URL in the HTTPS box (you'll need to remove https:// at the beginning of the url - its implied in the box). For connection type, select 'HTTPS' (not auto). Set you username and password to the portal username and password. Sync. Enjoy. If you want to use direct http on the LAN, you'll need to use a different connection profile rather than add the HTTP settings. The credentials will be different! Michael.

Benoit, they do appear to support basic auth with the uri format https://username[emoji14]assword@host (this is an RFC requirement) - but I think there will be an problem with usernames that contain @ - and since ISYPortal uses email addresses as usernames.... Sent from my Nexus 9 using Tapatalk

Should be, though I haven't tried it. The rest api works the same, but with the credentials being Portal user credentials instead of ISY credentials. You could create a secondary user for Maker to use - but - I have not tested if Maker can user usernames that are email addresses - having an @ in them might cause a problem. There is a solution pending for this, but I don't know the timeframe. That aside - I'll test it tonight... Hopefully. Sent from my Nexus 9 using Tapatalk

Thanks! That what I thought deep down.

Maker will not make non-ssl requests. Period. Nobody should - its not secure and you are telling your ISP, their ISP and every carrier in between your ISY password and username. There are no errors, because they simply ignore non-ssl rules to protect you from yourself. Not only does it need SSL, but it needs SSL that they trust. So, not self signed. Not cacert.org. A fully trusted certificate, and that likely means a paid certificate and a custom domain name (most CAs won't issue to dynamic DNS domain names). The Portal has a fully trusted SSL certificate, allowing you to use this with the Maker channel if you don't want to setup the domain name and trusted SSL yourself. It will likely have other features soon-ish to make Maker channel integration even easier. Personally, I'm excited about this one! Sent from my Nexus 9 using Tapatalk

Question. If you dim from 100% to 90% with a ramp rate of 3 minutes, will it take 3 mins to get to 90%? If so, couldn't this be repeated to achieve a 100% to 0% dim over 30 minutes? Sent from my Nexus 9 using Tapatalk

Plus there are several zwave thermostats that also directly talk to a zwave enabled ISY. Plenty of options. Best to stay away from proprietary thermostats if you want to integrate them into a home automation system with minimal pain. Sent from my Nexus 9 using Tapatalk

Is the program individually turning on multiple devices on after the other, or are the devices in a scene and the program is triggering the scene? Or some hybrid (program turning on several scenes, each scene with one or more members)?