2
votes

I'm having the SSL warning messages all over my website after switching to SSL for several assets:

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure script 'http://example.com/script.js'. This request has been blocked; the content must be served over HTTPS.

  • I checked the page source, every single script/css is requested over https.
  • I even checked the dynamically created html by using the code inspector.
  • I disabled Javascript in case a script was loading these assets dynamically.

None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?

2
In which browsers?sideshowbarker
Chrome, Firefox, Safari, Opera, Maxthon Cloud, Android stock browserNaturalBornCamper
So did you find anywhere in your source that’s requesting https://example.com/script.js (that is, the https version of the URL it’s reporting)? Regardless, if you put https://example.com/script.js in your browser address bar, does it resolve or does it instead just redirect to http://example.com/script.js (non-https)?sideshowbarker
You got it! It's redirecting some https:// assets to http:// but not all of them, only some. I'm guessing the nginx server has some configuration file messing this up somewhere..NaturalBornCamper
Cheers, glad you got it figured out. Yeah, I think that can happen if somebody has gone through and just changed the http URLs to https without checking to see if they redirect. I’m not sure if there’s a good answer yet at Stackoverflow about how to catch that, so I’ll try to formulate one right now and add it as answer so we have one here.sideshowbarker

2 Answers

3
votes

When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:

  1. Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
  2. If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
0
votes

My 2 cents regarding this issue.

I have a project hosted on one domain that works flawlessly.

I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.

Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.

First things first, I checked these 3 things:

  1. I check in the Network tab in dev tools and it is actually loaded through https.
  2. I open the file directly in browser and it is https.
  3. I try to open it as http:// and it automatically redirects to https://

This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.

After doing some investigation I found out the issue:

The call that was 'buggy' was ending in /. For example, all other calls were made to:

https://example.com/api/posts
https://example.com/api/users

And this particular one was making requests to

https://example.com/api/todos/

The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.

If I figure out what caused the / to fail so miserably, I will post an update.