Here’s the notice that landed in my inbox:

If your site URL does not support HTTPS, then this notice directly affects you. Even if your site does not have forms, moving over to HTTPS should be a priority, as this is only one step in Google’s strategy to identify insecure sites. They state this clearly in their message:

The new warning is part of a long term plan to mark all pages served over HTTP as “not secure”.

The problem is that the process of installing SSL certificates and transitioning site URLs from HTTP to HTTPS—not to mention editing all those links and linked images in existing content—sounds like a daunting task. Who has time and wants to spend the money to update a personal website for this?

I use GitHub Pages to host a number sites and projects for free—including some that use custom domain names. To that end, I wanted to see if I could quickly and inexpensively convert a site from HTTP to HTTPS. I wound up finding a relatively simple solution on a shoestring budget that I hope will help others. Let’s dig into that.

Enforcing HTTPS on GitHub Pages

Sites hosted on GitHub Pages have a simple setting to enable HTTPS. Navigate to the project’s Settings and flip the switch to enforce HTTPS.

But We Still Need SSL

Sure, that first step was a breeze, but it’s not the full picture of what we need to do to meet Google’s definition of a secure site. The reason is that enabling the HTTPS setting neither provides nor installs a Secure Sockets Layer (SSL) certificate to a site that uses a custom domain. Sites that use the default web address provided by GitHub Pages are fully secure with that setting, but those of us that use a custom domain have to go the extra step of securing SSL at the domain level.

That’s a bummer because SSL, while not super expensive, is yet another cost and likely one you may not want to incur when you’re trying to keep costs down. I wanted to find a way around this.

We Can Get SSL From a CDN … for Free!

This is where Cloudflare comes in. Cloudflare is a Content Delivery Network (CDN) that also provides distributed domain name server services. What that means is that we can leverage their network to set up HTTPS. The real kicker is that they have a free plan that makes this all possible.

It’s worth noting that there are a number of good posts here on CSS-Tricks that tout the benefits of a CDN. While we’re focused on the security perks in this post, CDNs are an excellent way to help reduce server burden and increase performance.

From here on out, I’m going to walk through the steps I used to connect Cloudflare to GitHub Pages so, if you haven’t already, you can snag a free account and follow along.

Step 1: Select the “+ Add Site” option

First off, we have to tell Cloudflare that our domain exists. Cloudflare will scan the DNS records to verify both that the domain exists and that the public information about the domain are accessible.

Step 2: Review the DNS records

After Cloudflare has scanned the DNS records, it will spit them out and display them for your review. Cloudflare indicates that it believes things are in good standing with an orange cloud in the Status column. Review the report and confirm that the records match those from your registrar. If all is good, click “Continue” to proceed.

Step 3: Get the Free Plan

Cloudflare will ask what level of service you want to use. Lo and behold! There is a free option that we can select.

Step 4: Update the Nameservers

At this point, Cloudflare provides us with its server addresses and our job is to head over to the registrar where the domain was purchased and paste those addresses into the DNS settings.

It’s not incredibly difficult to do this, but can be a little unnerving. Your registrar likely has instructions for how to do this. For example, here are GoDaddy’s instructions for updating nameservers for domains registered through their service.

Once you have done this step, your domain will effectively be mapped to Cloudflare’s servers, which will act as an intermediary between the domain and GitHub Pages. However, it is a bit of a waiting game and can take Cloudflare up to 24 hours to process the request.

If you are using GitHub Pages with a subdomain instead of a custom domain, there is one extra step you are required to do. Head over to your GitHub Pages settings and add a CNAME record in the DNS settings. Set it to point to <your-username>.github.io, where <your-username> is, of course, your GitHub account handle. Oh, and you will need to add a CNAME text file to the root of your GitHub project which is literally a text file named CNAME with your domain name in it.

Here is a screenshot with an example of adding a GitHub Pages subdomain as a CNAME record in Cloudflare’s settings:

Step 5: Enable HTTPS in Cloudflare

Sure, we’ve technically already done this in GitHub Pages, but we’re required to do it in Cloudflare as well. Cloudflare calls this feature “Crypto” and it not only forces HTTPS, but provides the SSL certificate we’ve been wanting all along. But we’ll get to that in just a bit. For now, enable Crypto for HTTPS.

Turn on the “Always use HTTPS” option:

Now any HTTP request from a browser is switched over to the more secure HTTPS. We’re another step closer to making Google Chrome happy.

Step 6: Make Use of the CDN

Hey, we’re using a CDN to get SSL, so we may as well take advantage of its performance benefits while we’re at it. We can speed up performance by reducing files automatically and extend browser cache expiration.

Select the “Speed” option in the settings and allow Cloudflare to auto minify our site’s web assets:

We can also set the expiration on browser cache to maximize performance:

By moving the expiration out date a longer than the default option, the browser will refrain itself from asking for a site’s resources with each and every visit—that is, resources that more than likely haven’t been changed or updated. This will save visitors an extra download on repeat visits within a month’s time.

Step 7: Make External Resource Secure

If you use external resources on your site (and many of us do), then those need to be served securely as well. For example, if you use a Javascript framework and it is not served from an HTTP source, that blows our secure cover as far as Google Chrome is concerned and we need to patch that up.

If the external resource you use does not provide HTTPS as a source, then you might want to consider hosting it yourself. We have a CDN now that makes the burden of serving it a non-issue.

Step 8: Activate SSL

Woot, here we are! SSL has been the missing link between our custom domain and GitHub Pages since we enabled HTTPS in the GitHub Pages setting and this is where we have the ability to activate a free SSL certificate on our site, courtesy of Cloudflare.

From the Crypto settings in Cloudflare, let’s first make sure that the SSL certificate is active:

If the certificate is active, move to “Page Rules” in the main menu and select the “Create Page Rule” option:

…then click “Add a Setting” and select the “Always use HTTPS” option:

After that click “Save and Deploy” and celebrate! We now have a fully secure site in the eyes of Google Chrome and didn’t have to touch a whole lot of code or drop a chunk of change to do it.

In Conclusion

Google’s push for HTTPS means front-end developers need to prioritize SSL support more than ever, whether it’s for our own sites, company sites, or client sites. This move gives us one more incentive to make the move and the fact that we can pick up free SSL and performance enhancements through the use of a CDN makes it all the more worthwhile.

Have you written about your adventures moving to HTTPS? Let me know in the comments and we can compare notes. Meanwhile, enjoy a secure and speedy site!

Switching Your Site to HTTPS on a Shoestring Budget originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.