elionce

>>Did you change anything else in the security settings? I didn't change anything after applying the update besides Network->Server Certificate->changing "key strength" to 1024->Self signed (and as mentioned, once I noticed that Mobilinc was working unreliably, I reverted back to 512 - so all settings are now the same as they were prior to the update). >>Can you access ISY using MobiLinc on the http port? If I change Mobilinc to use plaintext (http), the error doesn't seem to occur (I never need to click 'retry,' as I do when using https since the update).

...And after several times of retrying syncing etc, the ISY has now become entirely inaccessible (even via the blue ajax interface), requiring a physical reset (aka yanking out the power cord). Addendum: I've verified the unreliable Mobilinc behavior on two physical devices (two different iPhones). If I keep hitting "retry" repeatedly on the message mentioned above, it will eventually work (I presume this is the same as killing the app & re-launching, as sometimes it works and sometimes not). Addendum 2: I just reverted the certificate to 512, and it's behaving the same, so it appears to be an issue created by the new firmware.

Alrighty, installed & created a new self-signed 1024-bit certificate. I can once again access the ISY via Firefox. ...Unfortunately, it seems to have broken compatibility with Mobilinc: it now shows "Connection Error - There was a problem connecting. Please verify connection settings" as soon as I launch the app. It doesn't do this every time, it seems to be sporadic - i.e. if I launch the app I'll see the message; if I kill it & launch it again, I might or might not (maybe 3 out of 4 times it fails). I've completely resynced Mobilic's settings (i.e. "Download All"). I've been using Mobilinc since I first got the ISY (years ago), and have never seen this message before, so it seems to have been caused either by the update or perhaps the slowdown of the 1024 certificate (it definitely feels noticeably more sluggish when accessing the blue ajax interface). So the update does seem to have fixed the Firefox issue, but created another

>>TLS performance has improved dramatically in 4.3.10. That's great to hear! When I do automatic upgrade, it offers version 4.2.30; I presume I need to download it manually from (http://forum.universal-devices.com/topic/16427-release-4310-rc5-is-now-available/),and update that way? Since it's marked as "RC," can this version still be considered 100% safe / long-term, like an official release? Thanks again~ Addendum: I'm updating from 4.2.18 (in case that's relevant)

Hi again, So, sorry to resurrect this thread, but it appears that the old 512-bit certificate is now causing issues on Firefox (since the 39.0 update) as well as IE (11). Posting here rather than a new thread because I believe this is the same issue: browser security standards are becoming more stringent and disallowing weak certificates. This time I confirmed on two separate computers that do not use browser syncing, and the issue exists on both. I'm unsure of the solution as the weakest certificate my CA will issue (2048) makes the ISY excruciatingly slow to use, but using the default 512 as suggested seems to continue causing issues Here's a screenshot of what I now see in IE (with no apparent way to proceed): http://screencast.com/t/AsNsvKc2ZQ0 And in Firefox: http://screencast.com/t/puIzPFqU Personally it's more important to get this working in Firefox. Any ideas...? Thanks again

Ok, so after some more digging, it looks like something is just messed up in this particular Chrome install. I setup Chrome in a virtual machine (running on the same host machine as shows the error), and I can skip past the invalid certificate as expected. If I use Chrome Sync to copy over all my settings to the new instance, the new instance still works while the original doesn't. So maybe they messed something up in an incremental update, etc. Anyway, sorry for the hassle....

>>1. Verify the system date and time is correct in the computer BIOS and OS? If not correct the time and date and reboot the computer system. Is/Was correct >>2. Change your primary DNS to 8.8.8.8 / Secondary DNS 8.8.4.4. Once this is done please open a command window and enter ipconfig flushdns. I was actually already using the Google public DNS. >>3. In Chrome / Settings / Advanced / Proxy Settings / Advanced at the bottom uncheck all *Use SSL* box. They appear to have been unchecked by default; only the TLS options were checked. >>4. Also do you happen to use Kaspersky Anti Virus? If so there is a option to skip scanning SSL / HTTP disable this option and report back. Nope, not using Kaspersky. >>5. Also verify if this problem goes away while using a tethered connection vs WiFi. Tethering (iPhone) does not resolve the problem. So in other words: no changes have been made above, as all settings were already as described - but the problem persists.

Correct; if I access via internal IP, Chrome lets me skip the invalid certificate warning: http://screencast.com/t/eaOWu34MHgU

Just tried it. With the ISY plugged in, it's the error shown above - with it unplugged, it becomes "timeout": http://screencast.com/t/PsTBJZ5S. Plug the ISY back in, refresh, and it again returns to the original error above.

>>I suspect your own domain is not actually going to ISY. The domain without a doubt points to my home's external IP, as I have other devices that I access through it (NAS, security cameras, etc). And the router is definitely forwarding port 5010 to the ISY, as it works via the dyndns.org address. Both my domain and dyndns.org resolve to the same IP when pinged. >>Can you click on the lock button on the address bar and inspect the certificate Inspecting the certificate both via the owned domain and dyndns.org show the self-signed certificate for the owned domain (the certificate I have installed on the ISY).

Chrome has been updated (now 42.0.2311.135, which it reports as latest), but same behavior. Some other points, if relevant: *I access the ISY over a nonstandard port (5010) *I access the ISY via my own domain. If I access it directly via the internal LAN IP, it allows me to ignore the certificate error: (http://screencast.com/t/wsbFDkWO). And super-weird, I have a second dyndns.org address I used to use years ago, before I bought my own domain - if I use that, it works too. However, it definitely has worked with my own domain, and still does in Firefox.

994i, firmware 4.2.18. I'm aware that there's newer, but after some past experiences where functionality was disrupted/broken after upgrades, I've tended to be as cautious as possible, only upgrading when truly necessary - for fear of something going awry & finding myself stuck with many hours of debugging to restore operation. If 4.2.30 addresses this Chrome issue however, I suppose it's time to give it a try... Or if 4.3.x is imminent, perhaps I should hold off for that.

It appears to be specific to Chrome. Currently using 42.0.2311.90.

I'm no longer able to access my ISY-994i's blue ajax interface in Chrome; it gives me the following error (http://screencast.com/t/xAsOLRKuiZyt), with no way to ignore it. Previously I got an invalid certificate error, but was able to "proceed anyway." I had at one point attempted to rectify the invalid certificate error entirely by generating a certificate from a CA authority & installing it on the ISY - but the ISY turns out to be far too slow to use anything above 512-bit, and the authority does not issue anything worse than 2048. Thus, after speaking with UDI, I reverted to just using the default certificate once again, and "proceeding anyway" past the errors. This doesn't appear possible in Chrome any more, and I'm now unable to control my device from it at all.