elionce Posted April 29, 2015 Share Posted April 29, 2015 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. Link to comment
Michel Kohanim Posted April 30, 2015 Share Posted April 30, 2015 Hi metal450, This is quite odd and an error that I have never seen before. My Chrome works fine here. Do you have the same issue with other browsers? With 4.3.x to be out imminently, we have improved HTTPS by almost 100% (still will take 4-5 seconds on the initial connection). With kind regards, Michel Link to comment
elionce Posted April 30, 2015 Author Share Posted April 30, 2015 It appears to be specific to Chrome. Currently using 42.0.2311.90. Link to comment
Michel Kohanim Posted April 30, 2015 Share Posted April 30, 2015 Hi metal450, I am using Chrome 42.0.2311.135 m and it works fine with my 4.2.30 firmware. What's your ISY's model number and firmware version? With kind regards, Michel Link to comment
elionce Posted April 30, 2015 Author Share Posted April 30, 2015 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. Link to comment
MWareman Posted April 30, 2015 Share Posted April 30, 2015 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."That's an unusual error - Chrome is reporting things are blocked because the host uses HSTS. Except that ISY doesn't. Odd indeed 4.2.30 has been *very* stable for me. Link to comment
Michel Kohanim Posted May 1, 2015 Share Posted May 1, 2015 Hi metal450, 4.2.30 is an official release so it better be robust. As MWareman suggested, the error you are getting is really strange. I think it would be best to upgrade your Chrome first and retry. With kind regards, Michel Link to comment
elionce Posted May 1, 2015 Author Share Posted May 1, 2015 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. Link to comment
Michel Kohanim Posted May 1, 2015 Share Posted May 1, 2015 Hi metal450, This is really strange. I suspect your own domain is not actually going to ISY. Can you click on the lock button on the address bar and inspect the certificate and make sure it's indeed the one you installed for ISY?With kind regards,Michel Link to comment
elionce Posted May 1, 2015 Author Share Posted May 1, 2015 >>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). Link to comment
Michel Kohanim Posted May 3, 2015 Share Posted May 3, 2015 Hi metal450, I am so very sorry but I really do not know what else to suggest. The error you are getting is definitely not something ISY supports (in TLS) and thus I still have to suspect that it's really not ISY that's responding but something else on your network. A quick test would be to unplug ISY and go to the same URL. With kind regards, Michel Link to comment
elionce Posted May 5, 2015 Author Share Posted May 5, 2015 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. Link to comment
Michel Kohanim Posted May 5, 2015 Share Posted May 5, 2015 Hi metal450, Thank you. Just to recap: this is an issue if and only if you access your ISY through your domain but not locally? With kind regards, Michel Link to comment
elionce Posted May 5, 2015 Author Share Posted May 5, 2015 Correct; if I access via internal IP, Chrome lets me skip the invalid certificate warning: http://screencast.com/t/eaOWu34MHgU Link to comment
Teken Posted May 5, 2015 Share Posted May 5, 2015 The following suggestions have worked for some people who have been impacted by this issue. 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. 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. 3. In Chrome / Settings / Advanced / Proxy Settings / Advanced at the bottom uncheck all *Use SSL* box. 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. 5. Also verify if this problem goes away while using a tethered connection vs WiFi. Link to comment
elionce Posted May 5, 2015 Author Share Posted May 5, 2015 >>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. Link to comment
MWareman Posted May 5, 2015 Share Posted May 5, 2015 Almost any modern AV tool does web scanning, which will often interfere with SSL in some cases. When viewing the certificate is the root serial number the correct one? Other than that the only other thing I can think of is the NAT device sending your internet source traffic to the incorrect node on your LAN. Michael. Link to comment
Teken Posted May 6, 2015 Share Posted May 6, 2015 >>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. <-- Please the command prompt and ipconfig flushdns and report back. >>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. <-- Are you using a laptop? If so can you connect directly with a Ethernet cable to the router. Disable the WiFi on the laptop and report back success / failure. Reply inline . . . Link to comment
elionce Posted May 6, 2015 Author Share Posted May 6, 2015 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.... Link to comment
Teken Posted May 6, 2015 Share Posted May 6, 2015 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.... Awesome! Ideals are peaceful - History is violent Link to comment
elionce Posted July 11, 2015 Author Share Posted July 11, 2015 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 Link to comment
Michel Kohanim Posted July 11, 2015 Share Posted July 11, 2015 Hi metal450, Please upgrade to 4.3.10 and either use 1024 or 2048 bit certificate. TLS performance has improved dramatically in 4.3.10. With kind regards, Michel Link to comment
elionce Posted July 11, 2015 Author Share Posted July 11, 2015 >>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) Link to comment
Michel Kohanim Posted July 12, 2015 Share Posted July 12, 2015 Hi metal450, 4.3.10 is an RC and should be extremely safe and robust. This said, it's still an RC and not an official release. With kind regards, Michel Link to comment
elionce Posted July 13, 2015 Author Share Posted July 13, 2015 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 Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.