HTTPS some times doesnt show green padlock


#1

It shows as being insecure, but if I simply refresh, it’s back to the green padlock. This appears to happen with any of the several domains I’ve hooked up with the LetsEncrypt public beta. Not sure if this is a browser problem, or a server configuration issue.

I did ./letsencrypt --certonly
then followe with ./letsencrypt-auto which configured apache for me on my Debian (Jessie) box.

A site that I still have, not really active just used for testing purposes now…
https://www.myminecraft.com is a good example. If i View Source, i find no occurrances of http:// so I’m not sure why this is happening or how to troubleshoot.

One of the sublinks to my xenforo forum however works perfectly fine.

Any ideas on how I can figure out whats going on and why this isnt showing as secure?


#2

Mixed Content: The page at ‘https://www.myminecraft.com/’ was loaded over HTTPS, but requested an insecure image ‘http://i.imgur.com/3xeNZ.png’. This content should also be served over HTTPS. (index):1
Mixed Content: The page at ‘https://www.myminecraft.com/’ was loaded over HTTPS, but requested an insecure image ‘http://i.imgur.com/SazRcTR.jpg’. This content should also be served over HTTPS. (index):1

See the Console of a web developer toolbar or the sorts.


#3

I’ve just tried your home page with the chrome developer tools open & there’s 2 jpg images that are http.

Spookily I had a similar problem a month ago when I initially started beta testing LE - what I did to find it: http://blog.retep.org/2015/11/04/fixing-https-mixed-content-issues-in-chrome/

Peter


#4

Thanks guys, this is very helpful.


#5

I just used that example with DevTools and found the issue on another site, great tip!!


#6

There are two things you can do if you want to avoid trying to find every single reference:

  1. Insert an HSTS header which causes clients to rewrite http links within your site to https (although it doesn’t seem to rewrite resources the client loads).
  2. Insert a content security policy header which tells the client to only load resources from https, even if they are referenced by an http link. If a resource isn’t available via https, it will timeout and not even try it via http.

Extra tip: If you want to have both protocols accessible while you find those references, one can rewrite the references to be in the format //example.com/rest_of_uri as that will cause the client to stay in the protocol they’re currently using and not jump between http and https all the time.


#7

one thing you can’t account for is sites with web apps that offer and support user generated or linked content i.e. forums where user posts a 3rd party remote image embedded on a forum post. Unless the forum specific app has provisions for handling such, then end user will still have mix content warnings. i.e. Xenforo has a image proxy and Discourse just uploads images to own domain serving so avoids mixed content warnings for images at least.


#8

The page https://www.myminecraft.com/ contains unsafe contents because it uses this stylesheet:

https://www.myminecraft.com/wp-content/themes/mmc_blue/assets/css/app.css

and this stylesheet contains the following line:

@import url(http://fonts.googleapis.com/css?family=Open+Sans:300,400);


#9

Certainly this is caused by Mixed-content (stuff loaded from http on a https site).
@ScottHelme has a nice blog post, which explains how you can fix this: https://scotthelme.co.uk/migrating-from-http-to-https-ease-the-pain-with-csp-and-hsts/