Notes from our HTTPS Conversion

Edit: This article was updated on 8/25/17 to include information about adding an HTTPS property for sites in the Google Search Console.

In July 2017, 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.

When the web was initially developed, 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.

Securing web traffic mitigates a number of potential routes that viruses, ransomware and other digital attacks could otherwise use to try and infect web users. 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. Activating site-wide encryption for all of our sites means that Finalsite websites will not display frightening security warnings displayed in users’ browsers.

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:

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 for commercial websites that rely on third-party ads for their income (because those ads are often served over their own content networks, which are notoriously difficult to encrypt). 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!

Below are instructions for preventing mixed-content errors, as well as other helpful steps you can take to ensure all of your site's functionality remains intact when it's served via HTTPS.

Correcting mixed-content errors:

  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 “//” will force that content to load using the site’s encryption.

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.

Verifying your Domain on Google Search Console

When you activate HTTPS for your site, it's a good idea to re-verify your domain on the Google Search Console (formerly Webmaster Tools) so that Google will take advantage of the secure connection capability when sending messages and interacting with your site. (See this Knowledge Base article for more information about configuring Google Search Console.) 

  1. Log into your Google Search Console Account
  2. Find the "Add a Property" option
  3. Click to add a new property, and enter the HTTPS version of your school's URL:

    image.png
  4. Click "Add."
  5. This will prompt you to re-verify your domain. If you have previously verified the standard HTTP property, you can select the same option you used to verify the non-HTTPS property and hit "Verify"

    This is the property that Google will now send messages and alerts to, as well as report on for page crawl, indexing, and organic search visibility statistics.

Other Considerations

Many site admins worry that adding encryption can slow down the speed at which pages are served (because the server has extra information to process 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 as we implement HTTPS for client sites about what you might need to do to prepare. If you have any specific questions or concerns, our Support team is always available to help.

Was this article helpful?
3 out of 4 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.