How to trace source of IE8 Security Warning? - security

I am getting the dreaded security warning when running my GWT web app under IE8:
"this webpage contains content that will not be delivered using a secure HTTPS"
It of course works fine with Firefox and Chrome.
I have taken a look at the requests with firebug and I see no HTTP requests.
I have also used both Fiddler and HttpWatch with IE and I still see no HTTP requests.
Can anyone provide me with some clues as to what else might trigger this warning?

There are certain snippets of Javascript that can also cause a problem. Please see:
http://blog.httpwatch.com/2009/09/17/even-more-problems-with-the-ie-8-mixed-content-warning/
Also, have a look through the pile of comments on:
http://blog.httpwatch.com/2009/04/23/fixing-the-ie-8-warning-do-you-want-to-view-only-the-webpage-content-that-was-delivered-securely/
Some of the commenters have found and fixed other causes of the warning too.

Related

Uses deprecated APIs 1 warning found Browser errors were logged to the console

I have added an image of the WordPress site where I am facing these two issues which are becoming a hurdle in my site to optimize for best practices. I tried to find its solution but got no understanding of how to do that in my website of WordPress.
Uses deprecated APIs 1 warning found
Browser errors were logged to the console
Screenshot from Chrome inbuilt dev tool
I have found the solution by removing this policy from htaccess file. It's an HTTP header. You can check your website HTTP headers.
Header set Expect-CT enforce,max-age=2592000,report-uri="https://example.com/"
here is some help on this issue I believe.
https://developer.chrome.com/blog/immutable-document-domain/

Clear all the cookies even download a new browser but again show "ERR_TOO_MANY_REDIRECTS" error

When i visit : here then it shows "ERR_TOO_MANY_REDIRECTS" error. Honestly say that I Clear all the cookies even download a new browser but again show "ERR_TOO_MANY_REDIRECTS" error. How can i fix this issue?
It seems it is not a browser/cookie issue. There could be many reasons for this issue. Most common will be:
The web server(Apache, Nginx, etc) is not properly configured.
A bug in Backend(PHP etc) script redirection.
Please post some more details about server, scripts etc so, you can get a better help.

Internet Explorer blocks request to https://localhost

My application runs on localhost (both front-end and back-end, but on different ports). FE runs on http, but BE is on https.
All modern browsers allow adding exception so that https://localhost is accessible.
Except IE and Edge.
I've tried every option I have came across but none worked. I've added both http and https versions of localhost to Trusted Servers under "internet options". Did not work. I've checked host file, cleared cache, checked security options ...
What baffles me is that the request should be POST, but somehow the IE network panel shows it as GET. Other browsers send OPTIONS followed by POST, but IE fires GET and blocks it. It never hits the server.
What should I do to fix this?
And yes, unfortunately I DO HAVE TO support old IE, damn!
Whoa, solved by accident.
There is also Swagger running on my BE localhost. When I've tried to access it in IE, it showed warning about the invalid certificate. And only then was I able to install that certificate to IE, so that even IE would accept it.
So now when IE finally has the certificate, the request passed.
No usefull error message has been shown at all, so it took me considerable time to solve it. Damned IE.

Display unsecure content in IE9

I have a large webproject that in IE9 doesnt display some of the pages elements since the browser deems them "unsecure" in some way. We can ask our users to enable "display mixed content" in IE9 but would of course prefer to solve this on the server side.
Ive used firebug to track the webtraffic and cant see any http:// requests beeing made via the net-tab. I thought this was what caused the error. Is there any other possible way to troubleshoot this.. I just dont know what elements or settings could cause this problem (since all our traffic seems to go through https it has to be something else IE is reacting to?).
Weve done some more searching and the error occured because document.write isnt allowed to print at all to our page in IE9. Its perceived as insecure.

SSL: Why does Chrome report mixed content? (Drupal 6)

I've just got a site running nicely with the whole site running through SSL, but Google Chrome is throwing a "This page contains some insecure elements" message, which isn't good in terms of end user trust-ability. All other browsers work fine, and give the golden padlock.
The site is a Drupal 6 e-commerce site, running on apache2, and the error appears in the front end as well as the admin area.
Does anyone know of any methods to find out exactly which elements are being considered insecure?
Edit: I've used Fiddler to check the traffic, and it really is all HTTPS. It even complains on the site holding page, which is very light and has no javascript etc on it...
It could be a browser issue? Have you tried restarting, or clearing all of your cache?
In Chrome, this is trivial. Hit ctrl+shift+j to open the developer tools, and it will plainly list the URL of the insecure content.
Try it on https://www.fiddler2.com/test/securepageinsecureimage.htm, for instance.
I just had a similar problem. Turns out it was a hardcoded background image URL in a CSS file.
You should particularly check any 3rd party stylesheets you are using, as they may hotlink to an image on another server.
Easy solution? Save those images to your server and change the URLs to relative paths in the CSS file.
Hope this helps!
Search the source for http:? Something like <Ctrl-U> <Ctrl-F> http: in firefox should do.
The insecure element is something loaded over insecure — non-https — connection, e.g. image, stylesheet, etc. you obviously need fully qualified URL to load insecure element/
Use Firebug plugin of Firefox. In the NET tab all file locations are shown clearly. Try to find any files that are obtained from http protocol.
It's probably related to this bug:
http://code.google.com/p/chromium/issues/detail?id=24152
Which is why a restart fixed it.

Resources