Jump to content
View in the app

A better way to browse. Learn more.
Universal Devices Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Can't access the AJAX interface in Chrome over https

elionce
in ISY994

Featured Replies

Posted

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.

  • Author

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

  • Author

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.

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.

Edited by MWareman

  • Author

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.

Edited by metal450

  • Author

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

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

  • Author

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.

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.

Edited by Teken

  • Author
>>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.

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.

 

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

  • Author

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.... :)

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! [emoji4]

 

 

Ideals are peaceful - History is violent

  • 2 months later...
  • Author

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 :)

  • Author

>>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)

Edited by metal450

  • Author

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 :(

Guest
This topic is now closed to further replies.
Go to topic listing

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.