Skip To Main Content
Preparing for the HTTPS Conversion
Justin Ober

Today, Finalsite announced plans to convert all of the sites that we host to be served exclusively via secure "HTTPS" connections.

When you view a webpage, the URL in the address bar begins with "HTTP." HTTP stands for "HyperText Transfer Protocol," and is a set of rules that browsers must follow in order to ensure that web content is displayed accurately in all browsers. Often, however, you'll see "HTTPS" at the beginning of a page's URL, usually with a lock icon in a reassuring green color. HTTPS adds "Secure" to the mix - it includes all of same rules as HTTP, plus encryption features that allow end users and servers to create secure connections that cannot be read by a third party.

In the before-times when the web was young, HTTP was the default setting for all web traffic. HTTP works great, but it has a major vulnerability: content sent and received via HTTP can be observed (and possibly modified) by an attacker. Using HTTPS negates this issue, because traffic sent and received via a secure connection is encrypted. Encrypted traffic can be seen, but it can't be read or modified because it looks like unreadable gibberish.

Encrypting web traffic closes a number of potential routes that viruses, ransomware and other digital attacks might take. It's an effective deterrent against identity theft, and helps ensure that private data remains private. Because reducing the spread of malware helps everybody, there is a pronounced effort these days to convert as much of the web as possible to use HTTPS. Toward that end, browsers like Google Chrome and Firefox are making moves to highlight the encryption status of the pages that they display as a not-so-subtle way to encourage website operators to embrace HTTPS for all pages on their sites. Defaulting to full encryption for all of our sites means that Finalsite websites will not display frightening security warnings to users.

Activating site-wide encryption is not a cure-all however, and it does bring some complications. First of all, when a site is secured but an individual page includes some content borrowed from another website that isn't secure, users will see a "mixed-content error:"

Mixed content errors

This can be aggravating or downright scary for some users, and site admins can take steps to reduce the number of these errors. On the site administration side this can be a significant project if the site includes a lot of third-party content. Sites that don't serve ads, and whose third-party content is limited to things like iFrame embeds on a few pages, are much simpler to secure - happily, Finalsite websites fall into this category!

For Finalsite site administrators, the fix for a mixed-content error is:

  1. Navigate in Composer to the page that's throwing the error.
  2. Find the content that's being served over an HTTP connection (if you're having trouble tracking down the source of the mixed-content error, online tools such as www.whynopadlock.com can help zero in on the cause).
  3. Edit that so that it uses a relative link rather than an absolute link (in other words, the link should like like this: "//domain.com/some/folder/path" rather than like this: "http://domain.com/some/folder/path").

Removing the "http:" entirely and just leaving "//" ensures that all content on the page loads via the same secure protocol.

To confirm that a site is loading as expected via HTTPS, you can open a new browser window and type "https://[yourwebsite]" to load the site on a secure connection.

In the past, encryption could cause pages to be served more slowly than they would load over a nonsecure connection, because the server has to process extra information for each page request. The more modern security protocols that Finalsite uses (coupled with the old-fashioned approach of adding server capacity) mean this is no longer a significant concern.

As more and more activities are shifted online, the consequences of poor site security become more acute. Finalsite's goal is to ensure that our clients - and the students, parents, faculty and others they represent - are protected by reliable, effective security measures. Moving to full-site security is an important part of that process. We'll be in touch with additional admin notices and other notifications about what you might need to do to prepare as we implement HTTPS for client sites. If you have any specific questions or concerns, our Support team is always available to help.



Explore More Recent Support Blogs