Moving your SSL certificate over to the MaxCDN platform is pretty simple. However, if your site didn’t have SSL before CDN and this is the initial SSL installation, you need to make sure there are no hard-coded links on any of the pages or within CSS/JS files. These can trigger security warnings in all browsers if the page HTTP links to are called through HTTPS/SSL. You shouldn’t treat this alert or warning as a potential safety breaker, but you should know it may cause visitors to abandon your website. Therefore, it’s essential to find the fix for HTTP inner links as soon as possible so your SSL makes sense.
Why Is This Important?
So far, it’s assumed that your website is working properly even though you have HTTP inner links on HTTPS-protected pages. There are two types of mixed content:
If you have mixed content on your pages, but your website wasn’t defaced (didn’t lose its form and styling), you have a passive mixed content case. Each HTML element has attributes based on how it instructs browsers to load content on it. HTML elements attribute that cause passive mixed content is src, which can be used in the following elements:
If there is an issue, your visitors will see a warning message similar to the one below:
However, your page would be operational and most of its content encrypted - aside from HTTP links of course. Otherwise, using HTTP inner links to load sensitive data, assets, or alter page behavior would present a threat to all browsers. Your pages would also appear broken for end-users. Mixed content of this type is called mixed active content and attributes used in offending elements are SRC, HREF, OBJECT, URL (CSS) and DATA:
- <script> → src
- <link> → href (CSS as well)
- XMLHttpRequest → object
- <iframe> → src
- CSS (@font-face, background-image,...) → URL
- <object> → data
Naturally, these elements will allow an attacker to repoint or redirect healthy traffic to locations he can use against you. This is the MITM (Man In The Middle) attack and it may be successful thanks to mixed content data on secured pages. Browsers will mercilessly block this content, leaving your page naked. CSS will be stripped from the content that was blocked as part of insecure files batch:
How to Fix the Problem
If the problem appears on regular HTTPS secured pages with content that is being loaded via the insecure HTTP protocol, you can control how the content behaves. Links with “http://” extensions need to change to contain the “s” part of HTTP protocol (https://) pointing out to an SSL-reserved port. A more elegant way of handling different protocols is to have only slashes where the port is expected “//”. so that page can use the protocol used to open the page itself:
- If the page was loaded via http links with “//”, it will be transformed to http://
- If the page was loaded via https links with “//”, it will be ultimately transformed to https://
Of course, this only applies to links that are loading content from your own domain, from a location you control. Using this tactic to load 3rd party resources, requires an additional step - contacting the owner of the 3rd party domain and requesting https support. As this solution seems far fetched you may consider using a different supplier for the files you were loading from an insecure domain(s).
If you have any questions or experience any issues, please reach out to the Support Team, live chat and ticket support are available 24/7.