Chrome Version 44.0.2403.89 m - Failed to load resource: net::ERR_INSECURE_RESPONSE

[Michael Gamble]

Hey All, just upgraded to the latest and (greatest?) Chrome Version 44.0.2403.89 m and am now receiving some new errors I've neevr dealt with before.

Obviously I know that the errors are trying to load https:// scripts and styles from the server, but the issue here is......  The site is not hosted on a secure server, only http://

Anyone else experiencing this issue or know if the Beta version 45 does the same thing?

Example site is located here: http://demo.myeventon.com and its throwing our errors for all the stylesheets and scripts being loaded on that site.

Thanks in advance for any insight to my issue (and I have seen, many others surfacing today as well)

Screenshot of errors:  http://pasteboard.co/29BUGBhh.png

Regards,
Michael

[Jukka Hälikkä]

I have the same issue, I had no other option but to rollback to version 43, since every single firewall management website, router management website and other embedded device management websites we use at work stopped working, because each page just gives the ERR_INSECURE_RESPONSE, and shows a "sad paper"-icon. Hope there would be a solution for this issue, other than installing every single self-signed certificate from all the 3000+ devices we've got.

Regards,

Jukka

[dhw]

This sounds like the following known bugs in Chrome 44.  Immediate patches have already been merged to M-45 and M-44, and a Chrome 44 update fix will be released soon.

https://code.google.com/p/chromium/issues/detail?id=501842  -  Redirect loop on some sites

https://code.google.com/p/chromium/issues/detail?id=505268  -  Forcing Wordpress sites to use https even when not directed

[akash nivja]

I am also facing the almost same issue. Here is the scenario:

1. Clear cache & cookies.

2. Hit URL with http protocol.

3. Due to secure page, it will hit the same URL with https protocol.

4. Now most of the static contents in page like CSS, JS & Image files will be blocked with error message in console as - 'net::ERR_INSECURE_RESPONSE'.

5. But on refreshing the page or if redirection from http to https not happening then it works fine.

[jann]

When this can be fixed? I downloaded the latest Chrome stable version and also beta version. But both report such error in my case.

[John Forsyth]

Same issue here, using version 44.0.2403.130 m. I get this error running development web sites on localhost, which only use self-signed ssl certificates. It results in pages & resources sometimes not loading (but sometimes they do), and Chrome constantly showing the "Your connection is not private" warning page, even though I've already added the site as an exception.

This didn't use to be an issue with Chrome until very recently.

[Mike Williams]

I do not believe the referenced bugs are the same. The Wordpress issue has been fixed. This is about Chrome removing it's cached temporary trust for sites with untrusted or self-signed certificates during a session. I believe this was intended to be implemented to trusted sites only and has mistakenly been applied to both trusted and untrusted sites. It's basically making Chrome unusable as most of the gear I connect to has self-signed certs.

[Mike Gill]

I am experiencing the SAME thing.  I used to use Chrome for ALL of my device management (firewalls, ACS, etc.) and now all I get is the sad face and a net::ERR_INSECURE_RESPONSE when working on Fortinet firewalls.  It is driving me CRAZY since I have been using Chrome for almost a year now for device management because it was the ONLY one I could get to work with all the features of a Fortinet.  I am using Version 44.0.2403.130 m and also seen the same behavior in the newest beta for 45 as well.

[Steve Berube]

We are experiencing the same issue. Also happens with 44 beta. In our case these are self signed untrusted certs that we click proceed to. Approx 10 to 25 mins later they become untrusted. Refreshing the page prompts to n proceed again. The issue we see without refreshing is all our api requests fail with err_insecure_connection due to the temporary trust expiring.

Even using chrome://flags and changing to a day doesn't help. Chrome 43 works fine.

[Steve Berube]

Any know if there is an update or bug track on this?

[Ryan Waters]

A couple co-workers and I noticed Fortigate's Web UI breaking for us today, too.  The chrome "sad face" appears after one or more failed XHR calls and these appear to be caused by the deprecation of Synchronous XML HTTP Requests in recent builds of Chrome.  Both synchronous and asynchronous XHR's are present in e.g. fweb_core_all.js.  I'm seeing this behavior in FortiOS 5.0.9; maybe it's fixed in a more recent build of the OS?

[PhistucK]

Synchronous XMLHttpRequest is not new, as far as I know. If anything, there were talks about removing the deprecation warning lately, but it should not affect the underlying implementation.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Ryan Waters]

I was informed by someone at Fortinet that this issue has more to do with how Chrome is handling self-signed certificates.  The following is related:

https://code.google.com/p/chromium/issues/detail?id=513903

https://code.google.com/p/chromium/issues/detail?id=473390

Workarounds for Fortigate users include:

- don't use a self-signed cert

- use an older version of chrome

- use an alternative browser

- don't use HTTPS

[PhistucK]

Oops, I meant, "The deprecation of synchronous XMLHttpRequest is not new".

☆PhistucK

[chandan gawri]

Hi,

I am also facing same problem on latest version of Chrome. Could some one please acknowledge if this problem fixed in next version of chrome.

Regards,
Chandan Gawri

On Wednesday, 22 July 2015 23:49:42 UTC+5:30, Michael Gamble wrote:

[chandan gawri]

On Tuesday, 1 September 2015 13:04:05 UTC+5:30, chandan gawri wrote:

Hi,

I am also facing same problem on latest version of Chrome(46.0.2490.6 dev-m (64-bit)). Could some one please acknowledge if this problem fixed in next version of chrome.

[chandan gawri]

Hi Michael,

Did you get anyway some reason why this things just works fine after refreshing page.

Regards,
Chandan Kumar

[chandan gawri]

Hi Mike,

Did you able to understand why this behave just fine on subsequent request.

Regards,
Chandan Kumar

[KGA]

Hi Folks still affected by this bug, please see acknowledged Chromium bug https://code.google.com/p/chromium/issues/detail?id=516808