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?
There are two things you can do if you want to avoid trying to find every single reference:
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).
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.
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.