Into the Vault: the HTTP-to-HTTPS Checklist

Last week, we transitioned WPShout (and all our other web properties) onto SSL, a major security step that also has numerous other benefits. This article documents a few important recurring “gotchas” in transitioning WordPress sites onto SSL.

SSL: Into the Vault

Here, we’ll give a short rundown on SSL. For simplicity’s sake, we’re ignoring the distinctions between SSL, TLS, and HTTPS. This lets us use the following shorthand: your site is “secure” when you access it via https://, which the site needs an SSL certificate to enable.

Why Move to SSL

SSL is absolutely crucial if you’re handling sensitive user information, but there’s no situation under which it’s not a Good Idea.

Putting your site under SSL encrypts—makes thoroughly un-stealable—the communication between your site and your users. Sounds better than the alternative, right? It is. SSL is absolutely no-exceptions crucial if you’re handling sensitive user information like credit card data or medical records, but there’s basically no situation under which it’s not a Good Idea.

Through user trust, an SSL certificate can impact non-“security-related” metrics.

Because it’s is such a Good Idea, users have come to associate SSL with a general level of trust. All big sites—Amazon, Google, YouTube, and so on—are SSL-only, and seeing an SSL certificate (a glowing green lock in the URL bar) is, to many users, a general indicator that they’re okay to interact freely with a site. So for your site, an SSL certificate might even impact non-“security-related” metrics like user engagement and conversion rates.

Another good reason to move your site onto SSL is that it’s now, finally, free.

Another good reason to move your site onto SSL is that it’s now, finally, free. As we wrote last week, Let’s Encrypt is now offering free-to-all SSL certificates, and our favorite host SiteGround has made an extra-mile effort to make using those certificates dead simple. Free SSL certificates are the way of the future, and of the present if you’re on SiteGround. (By the way, if you’re not on SiteGround and want to be, check out our SiteGround deal offer in last week’s article!)

Moving Your Site into the Vault

So what does the move to SSL look like?

Everything you’ve brought into the vault has cleared security, and when your users come into the vault to visit you, they clear security too.

If you’re a fan of the Fallout series of video games, you can think of SSL like a vault. You used to live in a home—comfortable and airy, but not particularly secure. Now you’re going to live in an underground vault, guarded by an elite security force—your SSL certificate provider. Everything you’ve brought into the vault has cleared security, and when users come into the vault to visit you, they clear security too. Nobody’s allowed along with them, which is wonderful because you can have as private a conversation as you like.

The rest of this article describes the transition from home life to vault life, and two general kinds of problems that crop up during this transition:

1. URL issues
2. Mixed content warnings

For each type of problem, I’ll list the specific instances I’ve run into, and the fix for each. Enjoy!

1. URL Issues: “I Didn’t Know You’d Moved”

The first set of problems occurs when various resources don’t know to find you in your vault, and are still showing up with important business at your house. In other words, they’re still looking for you at http://site.com instead of https://site.com.

Some specific incarnations of this problem include:

Multiple Site Versions

It’s quite possible to have two site versions running at the same time: one at https://domain.com, and one at http://domain.com.

Just because you’ve installed an SSL certificate doesn’t mean your site automatically uses it. It’s quite possible to have two site versions running at the same time: one accessed through SSL at https://domain.com, and one accessed insecurely at http://domain.com.

This is like maintaining two addresses: one at the vault, one at your old house. This could have really dire SEO, security, and other consequences, as half of your traffic hits the unsecured version of your site—entering credit card data insecurely, viewing broken content, creating extreme confusion around your site analytics, and who knows what else.

The cure for this is to use .htaccess rules to permanently redirect all http:// traffic to https:// on your domain. My article from Thursday covered how to do this, and linked to the relevant working code on Stack Overflow.

Disqus

We use, and highly recommend, Disqus commenting in place of WordPress’s default commenting system. Earlier today, I noticed: no comments were showing up! Disqus was still expecting to serve comments to http://wpshout.com. I had to make the following change for a fix:

2. Mixed Content Warnings: “Your Friend Doesn’t Have Clearance”

Mixed content warnings occur when you try to bring something insecure—which hasn’t gotten past vault security—into the vault. Remember, the vault has strict security procedures, which is the whole point of the vault. No exceptions!

So mixed content warnings occur when a secure SSL site is still making an insecure request for a resource, like an image, JS file, or CSS stylesheet. Some specific issues include:

Insecure Image Links

The biggest single cause of mixed-content warnings in a WordPress environment are insecurely written image src attributes. Remember: http://site.com/media/image.jpg still exists even once your site is under SSL.

So if you put your site under SSL and reload your site, you’ll get about a million mixed content warnings that look like the following:

Note that the SSL certificate is no longer the comforting green lock you’d expect, and the “Console” tab of your browser inspector now points out mixed content.

One Problem, Multiple Locations

Insecure image links can live in a few places, and you have to address each differently:

In the WordPress Database

This is the most common source of insecurely referenced images, because the <img> tags we write to insert images into WordPress post content always specify the whole URL, up to and including the http part. Fixing this involves a block find-replace through your database with a tool like searchreplacedb2; I covered this in Thursday’s article.

In Theme Files

In the example above, the insecurely referenced image is WPShout’s logo, which in our case is hardcoded into our theme’s header.php. You may have several of these hardcoded theme-specific image links across the site; you’ll have to rewrite them manually in your theme, since the insecure references exist not in your database but in the PHP theme files themselves.

In Plugin Files

This is the rarest case, and probably the trickiest. Some third-party plugins directly reference insecure image content—the only example we’ve run across is a social sharing plugin we were using trying to pull in an insecure version of the Reddit logo.

Since manually changing third-party plugins means you can no longer accept plugin updates, it’s a sticky problem. A first suggestion is to see if you can live without the plugin. (In our case, we could.) If not, you may want to write a second plugin that modifies the first plugin to access resources securely—which, depending on the original plugin’s code, may be a bit of a brain teaser for a slow afternoon.

Insecurely Requested Google Fonts

A very common culprit for insecurely referenced content is: insecurely written Google Font resource requests. They look something like the following:

<link rel='stylesheet' id='open-sans-css'  href='http://fonts.googleapis.com/css?family=Open+Sans%3A300italic%2C400italic%2C600italic%2C300%2C400%2C600&subset=latin%2Clatin-ext&ver=4.5' type='text/css' media='all' />

The thing to notice here is the href='http://fonts.googleapis.com/. This code translates to “Please fetch this font file insecurely from a third-party site, and then use the results to render text on my secure site.” Your browser isn’t going to like that at all, causing console errors like:

If this is the only way you’re pulling in those fonts, you’ll notice something else, too: none of your Google fonts work, because your browser blocked them as a potential security threat.

These insecurely written references can live in multiple places, too. The example above corresponds to a Google font request that’s been pasted directly into the site’s header (and would live in the theme’s header.php). There are also Google font calls that live in theme or plugin CSS stylesheets, and look like this:

@import url(https://fonts.googleapis.com/css?family=Merriweather:400,400italic,700,700italic);

In either case, the solution is the same: to rewrite the url to start with https://.

Enjoy Vault Life!

Together with last week’s video guide, this list of specific problems that crop up should give you a lot of confidence to move your site into the windowless underground vaults of SSL. It’s better down here!

If you have any questions at all, or are hitting bugs in your own transition, please don’t hesitate to comment. Thanks!