Converting Sites From HTTP to HTTPS

For large sites, switching from non-SSL to secure pages can require paying attention to a lot of details. I'll describe some of them and in general what to watch for.

It's a good time for me to write this article because conversion of Willmaster.com into an all-secure connection site is currently in process.

We've had the SSL certificate for years. It was used for secure forms such as the one where FTP and other login information is provided.

I've been procrastinating about converting the entire site because it seemed a daunting task.

But now we're doing it.

If yours is a large site, or one with lots of content pulled in from various locations on your sites and/or from other people's sites, this is for you. What follows are things I have learned that may make things easier.

The first thing to do is get the secure ("SSL") certificate (assuming you don't already have one).

The SSL certificate can be on your server without being used. Therefore, having it doesn't imply a rush to get going on converting the site. But you do have to have it before conversion can begin.

At the willmaster site, we're doing one section at a time — the /blog/, the /library/, the /software/, etc. We can do the conversion for a section, test its pages, tweak what needs tweaking, and be done with that one.

When doing a section at a time, it means that some sections of your site is http://... and some is https://... . during the conversion process. Pulling resources from non-secure sections is likely to break the lock icon in the browser. Cross linking might also present special issues.

For converting one section at a time, make absolute URLs to pages within the same domain begin with // instead of https://. The reason is this: Whether the browser has currently loaded your page with HTTP or with HTTPS, the URL will match the protocol.

URLs beginning with // are relative URLs.

If the browser loaded http://example.com, a link to //example.com/page.php will be loaded as http://example.com/page.php. Similarly, a page loaded at https://example.com with a link to //example.com/page.php will be loaded as https://example.com/page.php when the link is clicked.

After your entire site has been converted, and if you want to (certainly not required), you can change the // URLs to https://. But while you're converting from HTTP to HTTPS, one section of your website at a time, let the URLs begin with //.

Which URLs Need to Be Converted to HTTPS?

The following applies whether you're doing an entire site all at once or doing a section at a time.

1. All src URLs need to to be converted.

   All content pulled into the page must be loaded with a secure connection. This applies even when the content is pulled in from someone else's domain.

   If the domain where you're pulling content from doesn't have an SSL certificate, the browser will refuse to display the secure padlock icon. The only solutions I'm aware of, to get the secure padlock icon in a case like this, are to (a) convince the domain owners to accept SSL connections or (b) stop pulling in content from that domain.

2. All href URLs in link tags that link to content to be applied to the web page. This is generally CSS files, but might also apply to other content.

3. Intra-site linking href URLs need to be converted.

   If your intra-site linking URLs are absolute URLs, they will need to be converted. Relative intra-site linking URLs won't need conversion.

   Conversion of linking URLs to other websites is not required. It is good practice to do so, however, if the site being linked to can serve the page with a secure connection.

4. All action URLs within form tags unless it is a relative URL.

5. All URLs that Ajax functions use to retrieve content except relative URLs.

Browsers look deep.

As an example, content pulled in with JavaScript that contains non-secure, absolute src URLs will prevent a secure padlock icon from being displayed. This applies even if the JavaScript pulls in other JavaScript, for many levels, and eventually content with a non-secure src URL.

Anything pulled into the page or used by the page must be accessed with a secure connection, no matter how many levels deep the content exists at.

Fortunately, at least some browsers provide tools to help locate non-secure gremlins.

Testing and Fixing Pages

Each page will need to be tested. Sorry, but it really must. It can appear somewhat unprofessional to serve a page without a secure locked padlock icon when all the rest of the site is secure.

When a page is loaded with HTTPS and no secure padlock icon is displayed, there is at least one non-secure URL related to the page that prevents a fully-secure page load.

The non-secure URLs need to be located and either fixed or removed.

When testing with Safari for Mac, the menu item Develop | Show Web Inspector can provide information you need to ferret out non-secure URLs that may be preventing the secure padlock icon from displaying. Use the "Console" tab, as it is most likely to provide the information you need.

When testing with Chrome for Mac (although PC Chrome probably works pretty much the same way), find the 3-vertical-dots icon in the browser's apps bar. There, find More Tools | Developer Tools. As with Safari, the "Console" tab is most likely to provide the information you need for locating non-secure URLs.

This article's intent is to be a guide for converting non-secure sites to secure sites. There is no intent to be comprehensive, but to provide a foundation of understanding and sufficient information for converting most websites to HTTPS.

Addendum:

There was somewhat of an unwelcome realization when the transition was nearly done — every http://www.willmaster.com/... URL in each Short URL V3 database had to be changed to https://www.willmaster.com/...

Instead of doing each one of hundreds separately via the Short URL V3 control panel, I wrote a script to do the job for me.

If you use Short URL V3, you may download the URL-change script and use it. Instructions are in the script itself.

Will Bontrager