Skip to main content

Blog

CleanSlate will move to HTTPS. Here's what you need to know.

We're moving all CleanSlate sites to HTTPS by fall 2015 (if not earlier) spring 2016. This means your sites could end up busted when we switch to HTTPS. To ready your sites for this move, please test and resolve any Mixed Content errors or warnings before we make the switch permanent.

This post will show you how to test your site for HTTPS and how to fix any errors that may exist.

What is HTTPS?

You've probably heard of HTTPS. Sometimes people refer to it as SSL. HTTPS is a protocol for secure communication over a computer network—in our case, the internet. Recently, there's been a big push to move everything to HTTPS to make the web more secure.

Imagine for a second if the web wasn't a safe place. Maybe you could get a virus after visiting Amazon or Google. You'd stop using the web for fear of security and privacy issues. Online banking? forget it. Luckily, this is not quite the case; but, after reading this list of shady stuff from Chris Coyier, you may realize this might not be too far fetched.

To make the web more secure, HTTPS adoption is becoming more widespread. Google says that they're ranking sites available over HTTPS higher in search results. Last year, Google called for " HTTPS Everywhere." Users also trust HTTPS sites. This helps the user experience and likely increases conversions.

Why should you care?

HTTPS encrypts web traffic, increases security and privacy.

"Hypertext Transfer Protocol Secure (HTTPS) offers the strongest privacy protection available for public web connections with today’s internet technology." - https.cio.gov

As people who make websites for WVU, we are largely responsible for making HTTPS support a reality. Our goal is to roll out HTTPS everywhere for CleanSlate sites by this fall spring 2016. Your site will redirect from http://example.wvu.edu to https://example.wvu.edu in the near future. You will not be able to access your site over HTTP after this change.

So what do I need to do?

Green lock means there are no errors. Yellow lock means there are some errors to fix. And red lock means you need to fix these errors ASAP.

HTTPS is actually available on your site right now. If you visit any production CleanSlate site (or Slate site, for that matter) and use HTTPS, you can see how the site looks when using HTTPS.

  • If you're a boss, everything will look perfect. You'll get that nice green lock in Chrome.
  • If you're lucky, you might have a few Mixed Content warnings to fix ( these).
  • If you're unlucky, your site could look completely busted!

This is why we're talking about HTTPS now. We want you to test your sites for HTTPS support. Resolve any errors before we make everything load over HTTPS. Get ahead of the curve so you don't have to put out fires later.

How do I test a page to see if it's ready for HTTPS?

  • Open up Chrome DevTools, click on "Console" and visit your page at https://example.wvu.edu
  • Once your page loads, two things might happen:
    1. Green lock = You're all good. You're site is ready for HTTPS.
    2. Yellow/ red warning lock = Check console and resolve the error messages.

NOTE: You can do this in Firefox and Safari too; but, Chrome does a great job of being in your face about Mixed Content and errors you may otherwise overlook in Firefox and Safari.

How to fix "Mixed Content" Warnings

Also known as: " Oh no, my site looks busted when using HTTPS?" If you link to an asset either from WVU or via a CDN, make sure you reference it with HTTPS, not HTTP. For example:

<!-- Incorrect: -->
<link rel="stylesheet" href="http://example.wvu.edu/stylesheets/styles.css">

<!-- Correct! -->
<link rel="stylesheet" href="https://example.wvu.edu/stylesheets/styles.css">

Note the subtle difference: one uses https instead of http to reference the stylesheet. This applies to stylesheets, javascripts, embedded content (YouTube, Twitter, etc) and images. Basically, any asset you could link to on your site. https.cio.gov has a great guide to mixed content if you need more detail.

If you link to any assets with a protocol relative URL, you should change the URL to use HTTPS.

Test your entire site for HTTPS errors:

  • For sites with less than 200 pages: run your site through JitBit's SSL Check. This service crawls every page on your site and returns the pages that need HTTPS love.
  • If you're site is bigger than 200 pages, check out Bram Van Damme's Mixed Content Scan.
    • Note: If you don't already have Composer installed globally, you'll need that before installing Mixed Content Scan.

Pro Tip: Install this Extension

Install the HTTPS Everywhere browser extension. This extension forces your browser to use HTTPS when it's available—including WVU pages listed in  their ruleset. This puts the errors in your face causing you to fix the errors before D-Day.

It's important to note WVU was recently added as a partial rule by this extension. See if you're site is listed. If it's not, you can get it added to their Atlas when everything on your site is tip-top. That way, all 850,000+ users of this extension will have a great HTTPS experience on WVU sites.

FAQ:

What's the best protocol (http, https, or //) when linking to resources?

https. For more information, see this image.

What about Slate?

HTTPS is available for Slate CMS too! You should follow these steps to test your Slate sites for HTTPS and fix any errors that may exist. You should especially do this if you're site is listed in HTTPS Everywhere's Atlas as users will be redirected to the HTTPS version.

What if my resource isn't available over HTTPS?

If it's not available over HTTPS, consider downloading and hosting it from your theme. If that's not possible, contact the company/owner and see if they can give you HTTPS support. If both of those options don't work, serve the asset via a protocol relative URL and hope HTTPS support comes in the future.

My site is on a sub-sub domain (example.mycollege.wvu.edu) and I get an error when I test HTTPS. What's the deal there?

The HTTPS certificate WVU owns at the time of this post is only allowed to certify *.wvu.edu, not *.*.wvu.edu. By this fall spring 2016, we're planning on having *.*.wvu.edu—so you should still ready your site for the HTTPS conversion. You can bypass the " Your Connection is not Private" page by clicking Advanced > Proceed to example.xyz.wvu.edu in Chrome. Afterward, use your DevTools Console to identify Mixed Content warnings and errors.

Other Resources

This screencast on Chris Coyier's HTTPS conversion is definitely worth a watch.

Everything on https.cio.gov is gold and worthy of your time.


As usual, if you have any questions or need help with something, please get in touch. We're happy to help.