How to fix mixed content SSL errors

So, your new SSL certificate is installed, but your site isn’t showing a green padlock in the browser. Instead, there is a yield/warning symbol in its place. In Firefox, it looks like this:

In Chrome, like this:

Chromium may show it like this:

Some pages may simply appear to be missing resources and render in such a way that they appear to be broken.

You’ve checked and confirmed that the SSL is installed correctly using tools such as the SSL Checker from sslshopper, and it indeed is. So, what’s the problem?

This is the Mixed Content SSL error, which indicates that the site isn’t fully secure due to the site’s code. The site’s code is using resources such as images, CSS, and JS via insecure http URLs rather than via secure https URLs.

Because the site is requested via https but not all content is delivered via https, a warning is returned from the browser. In some browsers, the page may even appear to be broken due to excluding those insecure resources in rendering. This is common with Internet Explorer. With these, you may observe a warning message stating, “Only secure content is displayed”.

Ultimately, changing those URLs in the site code so that they use the https protocol instead of http is required to resolve the issue. Alternatively, one could change all URLs in the site code so that they load all resources without specifying the HTTP or HTTPS protocols, resulting in the site using whatever the parent site uses (ideally you’ve added a http to https wildcard redirect for the parent site and so all URLs will use https). You will use // instead of http:// for your URLs. (i.e., //domain.com/path/to/file.ext instead of https://domain.com/path/to/file.ext.

Viewing the Content that is Served Via http Using Your Browser’s Developer Tools

In case you’d like to confirm that content is being loaded via http instead of https in your site, you can view the exact URIs in your browser’s Developer Tools. You can Right Click on the page and choose the option to Inspect the site. You’ll see the browser’s developer tools open. Then choose the Console tab. This will show you exactly what URIs are included in your site via http rather than https. Those are the URIs that will need to be converted. This method is particular useful for those custom scripted sites that require manual code edits in order to rectify this issue. You can also use the Security and Network tabs to view information (URIs) of the insecure content.

Some browser-based tools exist, but one of the most popular is www.whynopadlock.com/. It will inform you of content being served insecurely and what the content is.

Fixing The Error

Once you know what assets are served insecurely, make sure to check that they can be served via https. If they can, go ahead and make those replacements of http with https.

To fix the error, one must simply replace all instances of http in the site with https or remove the protocol specification altogether. If any external resources are used by the site that are not available via https, then one would need to replace that resource with another similar resource that is available via https. Other options include removing the resource or hosting the resource locally.

Some Content Management Systems make fixing this error easy via extensions, plugins, addons, etc. With WordPress, the following plugins will more often than not resolve the issue:

wordpress.org/plugins/ssl-insecure-content-fixer/

en-gb.wordpress.org/plugins/really-simple-ssl/

Alternatively, one could use WP CLI’s Search and Replace to find all insecure URIs in the database and replace them with their secure version. You could use grep to search for them within the files residing in the document root of the site. and then replace each occurrence accordingly.

  grep -Rli "$insecureURI" /home/$USER/docroot

Another method would involve Cloudflare. With Cloudflare, you can choose to enable Automatic HTTPS Rewrites to help with this issue. Understanding Automatic HTTPS rewrites. This method doesn’t always work with Javascript, though, so rewriting the URLs manually in the site’s database and code is the best and most permanent option overall.

If you have any questions about this issue, please don’t hesitate to submit a support request to your KnownHost support team, who is available 24/7 and always willing to help! 🙂