How to Switch to HTTPS

This guide will give you the steps involved in a successful move on how to switch to HTTPS from HTTP.

READ LATER - DOWNLOAD THIS POST AS A PDF CLICK HERE

Overview – getting ready

1. Pre-move

Before actually moving you’ll want to prepare a little, this includes selecting the sort of SSL certificate you want ready in case you need to purchase it in advance.

2. Moving day

Time to get/buy, install and check the SSL certificate, fix mixed content issues, set up redirects and check 3rd party integrations.

3. Post-move

Shortly after the initial move, check for new issues. Then once ready, setup the site to always use HTTPS.

4. Going above and beyond

Fixing further issues & similar security improvements.

1. Pre-Move

Selecting an SSL certificate

As most SSL providers now supply a 2048-bit key or higher by default, your first question is, what sort of certificate do you want?
There are 3 main types of certificates you can choose from for your site:

Domain Validation (DV)
– Standard SSL (just as secure as other options).
– Free via Let’s Encrypt & Cloudflare, or purchase available.
~ Normally issued in minutes.

Organization Validation (OV)
Shows organisation within certificate but largely appears the same as DV.
– Requires purchase.
– Can take several days to issue.

Extended Validation (EV)
– Shows organisation in URL bar as well as within the certificate.
– Requires purchase, more expensive.
– Can take up to a week to issue.

For most sites, DV certificates are exactly what you’re looking for. But it’s worth considering EV certificates as they show the organisation in the URL bar. Another consideration is do you need this certificate for a single domain /subdomain or for multiple. There are single domain, multi domain and wildcard (all subdomains) certificates available from most SSL providers, though Let’s Encrypt & Cloudflare require you set up each subdomain separately.
If you’re just looking to secure your main domain, a DV or EV certificates will work perfectly

Free DV certificates are available with Cloudflare (https://www.cloudflare.com) and Let’s Encrypt (https://letsencrypt.org)
Many hosting providers offer certificates but can be expensive. We on the other hand offer certificates at competitive prices, are quality brand names and provide the install and testing.

If you’re interested in an OV or EV certificate, best to go ahead and purchase these in advance as they can take several days to be issued. They will also require proof of the organisation’s existence. But if you’re selecting a DV certificate then you can wait until the moving day.

Once you’ve selected the certificate, you’re interested in you can move on and start the migrating, but consider the following points to make sure you don’t miss anything first.

1. Load Balancers
If you use Load Balancers in front of your web servers, then you’ll later be installing the certificates onto these instead of the actual web servers. Some load balancers such as AWS ELB offer free SSL. Check to see if your hosting/provider already offers FREE SSL.
Though this is not yet the norm, as HTTPS becomes the default for a lot of sites, providers are starting to offer SSL included with hosting packages. It’s worth contacting them to be sure.

2 .Do you have a test site?
This is optional as you can make these changes first would reduce the risks before going live on your main site.

3. Dedicate some time to your migration.
Installing a certificate can be pretty quick, though the actual full migration
process can take a good chunk of time to properly complete. We’d advise starting the moving day portion of this guide when you have a few hours free. If everything goes smoothly, it may take less time, but it’s worth having that spare time just in case.

4. Communicate
Make sure everyone involved in the site knows the migration is happening. For example, if your site has a separate marketing person or team, let them know what will be changing. Later on, we’ll be updating 3rd party links, and they may need to be aware of the changes and make changes of their own.

5. How will you track changes?
If the migration causes some short-term disruptions in traffic and search rank, you’ll want stats to fall back on and provide visibility of what exactly changed. If you haven’t already, set up Google Analytics (https://www.google.co.uk/analytics!) or a similar service and let it run for at least a week to get a good idea of current traffic & behaviour. It’s also worth making sure you have Google Search Console (https://www.google.com/webmasters) (Webmaster tools) set up to track indexed pages and keywords used to find your site along with average position. You may also want to check out Bing’s Webmaster Tools (https://www.bing.com/toolbox/webmaster).

6 . Consider making some changes pre-migration.
Some changes such as fixing mixed content can often be done before the move. We’ve listed it later on as part of the migration flow, but feel free to skip ahead through the guide to ease the changes later. Other changes such as redirects & 3rd party changes must wait until you first have SSL installed.

7. Do you plan to move your entire site or specific areas first?
If you can, move your entire site. It means more work upfront but given the SEO benefits and knowledge that your entire site is encrypted for users is worth it in the long run. However, not all sites are able to do this at once, at the very least you’ll need to setup HTTPS for any login forms, payment pages and any pages that require or reveal user details.

8. Site redirects
The rest of guide currently assumes you’re moving your entire site so some parts of this you can skip or modify. E.g. you’ll want to skip changing most 3rd party settings if the majority of your site is still over HTTP instead of HTTPS. You’d also want to not set up an entire site redirect, but instead, redirect just the specific pages/sections over HTTPS and potentially setup redirects going the other way for pages required over HTTP from HTTPS.

9. Does your site have multiple variations?
During the migration, you’ll need to be aware of all variations of your site such as multiple languages or location-based changes or even AB tests in progress? During the mixed content fixing step you’ll need to check all variations.

10. Using a CDN?
Check out your CDN’s site to see if there’s anything you need to change/be aware of during the migration process.

2. Moving Day

Got your certificate?
At this point, if you haven’t previously got your SSL certificate, now is the time to do so.

Already have your certificate?
Skip this step and proceed to install. If you’re looking to use Let’s Encrypt‘s free certificates and you’re installing the certificates over SSH then Certbot (https://certbot.eff.org) will walk you through this & set up automatic renewals.

If you want to use Cloudflare’s free certificates, all you need do is sign up with them and move your name servers to them which their site will guide you through this process. Once signed up and your site is running through Cloudflare, you could opt to use the Pro plan which offers older browser support for SSL.

In order to purchase a certificate from any 3rd party, you will need to generate a Private Key & a Certificate Signing Request (CSR) on your web server. You will only need the CSR, but the private key is required on your server.

We can do this for you with our expert install service

The site you’re purchasing from should guide you through this, but just in case: Digicert have a useful support page (https://www.digicert.com/csr-creation.htm) listing multiple platforms & operating systems each linking off to how to generate your CSR.
Also, GoDaddy has some useful documentation (https://uk.godaddy.com/help/install-ssl-certificates-16623?) on this as well. These also include generating the private key at the same time. E.g. Digicert offer a QpenSSL CSR Creation (https://www.digicert.com/easy-csr/openssl.htm) which generates a command you can run via ssh which generates both the CSR and private key file.

Install the certificate
Using the Mozilla SSL Configuration Generator (https://mozilla.github.io/server-side-tls/ssl-config-generator/) you can build the config needed to add to your server config files. e.g. if using Apache2, you’ll need to either change your .htaccess or apache.conf file. Then upload the certificates to the paths shown in the config, e.g. /path/to/signed certificate. This tool can also add the HSTS (Strict-Transport-Security) header to the config, you could choose to add this now, but we’d advise holding back, we’ll go over later in the guide.

If you use Load Balancers in front of your site’s servers, you will likely need to install the SSL certificate on the load balancer instead of each actual web server.

Check the certificate
First check, before any others, load the site up in your browser (make sure to load the HTTPS version). Are any issues shown in your browser? no? brilliant!
However, if you do see an error message, the message may point you in the right direction, but SSLLabs (https://www.ssllabs.com/ssltest/) can be used here to
check and diagnose the issue.
If needed, this article (https://mau/wujjf.ole/research/ssl-debugging.htm/) can be very useful in debugging typical SSL issues, though the post is fairly technical.
You hopefully won’t see a full page error screen, though you may find you don’t have a green lock / HTTPS indicator in the URL bar. Which brings us onto the next subject, fixing insecure/mixed content issues.
If the site does not load over HTTPS at first, check Admin > Redirect Manager for any redirects that may have pointed away from HTTPS.

Finding Mixed Content Issues
Mixed content is when you have assets/resources on pages that try to load over HTTP instead of HTTPS. This affects images, scripts, css and more. There are 2 types of mixed content, the first is active mixed content, things like javascript files that could change the content of the page if intercepted by a man- in-the-middle (https:Uen.wikipedia.org/wiki/Man-in-the-middle attack. This is often blocked in browsers but can leave parts of your site broken because of this. The other type is passive mixed content, such as images, which are less dangerous, but still an issue and though not blocked in the browser, having these will replace your green HTTPS & lock symbol with a grey version indicating it’s over HTTPS but has issues.

There are a few ways to find mixed content on your site; the simplest is to load up pages and use your browser’s developer tools to see warnings. But doing this over an entire site would likely be either very slow or impossible.
Instead, the main ways sites are normally checked are through: Using a tool to externally crawl your site.
These crawling tools work with any site as they are run externally. Here are some examples:

1. HTTPS Checker (https://httpschecker.net/guides/https-checker) is a desktop app (available on Windows, Mac OS X & Ubuntu Linux) to crawl a site for mixed content and related issues.

2. Mixed Content Scan (https://github.com/bramus/mixed-content-scan) by Bramus is a command line php script that will crawl a given site for any mixed content issues.

3. SSL Check (https://www.jitbit.com/sslcheck) byJitBit offers a quick online tool to find mixed content – though is limited to 200 crawled URLs.

If your site is a WordPress Theme there are plugins dedicated to HTTPS migration help, these will also assist in the following steps so worth checking them out before continuing.
For WordPress sites, these are usually our recommended way to go but could be combined with the tools above to be extra safe.

1. Really Simple SSL (https://en-gb.wordpress.org/plugins/really-simple-ssl/)
2. SSL Insecure Content Fixer (https://en-gb.wordpress.org/plugins/ssl-insecure-content-fixer/)
3. CSP (Content Security Policy) reporting, which is a way to tell browsers to send issue reports back to you as users navigate through your site. It’s usually regarded as the complete option as it catches any ajax issues that crawling may not find, though it requires you first have users visiting pages with mixed content on to report them. It also only works if you have access to modify the HTTP response headers of your site; plugins can often accomplish this though. CSP violations can be sent back to a central server for you to monitor them and receive alerts, here are a few examples:

1. Report URI (https://report-uri.com/) – Offers free hosted CSP collection, great graphs and tools to build a CSP header.

2. HTTPS Reporter (https://httpschecker.net/guides/https-reporter) – Paid CSP hosting provides you with a prebuilt CSP header designed just to catch mixed content issues ready to set up on your site.

3. Casper the friendly CSP Report Aggregator (https://github.com/TryGhost/Casper) – Though no longer under active Development, this is an open source CSP service you can run on Heroku. Or you could build a script yourself
(https://mathiasbynens.be/notes/csp-reports) to collect your CSP reports.
Once you’ve got a good way to identify any mixed content issues on your site you can start fixing any found.

5. Fix mixed content
The above WordPress plugins can help fix issues, the following will help with areas you need to manually change though.
The essence of fixing mixed content issues is to replace links to HTTP resources with HTTPS.

E.g. <img src="http://site.com/image.png" /> Would need replacing with <img src="https://site.com/image.png" />

to load over HTTPS instead. Sometimes an HTTPS version of something may not yet be available, in this case you could download the resource and host it yourself on your newly HTTPS site. Another option to help the migration process is to use the CSP header of “upgrade-insecure-requests” (Browser support is fairly good and improving) (https://caniuse.com/#). You can read more about this here
(https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content#up_grading insecure requests). This is probably the nicest way to do it but requires the resource to have an HTTPS version available, so worth checking or reporting these issues too. You could also use CSP set to block all non HTTPS requests, though this will result in broken images, style & scripts, so using this with the reporting services above would be wanted.

To test
Recheck your site with the tools used in the previous steps. Check all forms & redirects are over HTTPS Usually grouped in with mixed content, forms that have insecure / HTTP actions set. This is because even if you redirect your whole site, the form data would still first be sent over HTTP to hit the redirect and then go over HTTPS, exposing the data in the ‘in-between’ HTTP step. The same is true for redirects such as redirects to URLs logged in areas of a site. The above-mixed content checking tools can help you track these issues down.

Setup HTTP to HTTPS redirect
In order to make sure users reach the HTTPS version of your site you can use a 301 redirect and send all requests to the HTTPS version.
Setup your .htaccess file with the following redirect to HTTPS:

RewriteCond %{SERVER_PORT} 86<br />
RewriteRule "( .*)$ https://site.com/$1 [R=301, L]

After setting this redirect up it’s important to test it doesn’t just send users to the homepage, but rather it redirect any request path to the same path but over HTTPS.

http://site.com/info/contact.html redirects to https://site.com/info/contact.html 

If you are on a wordpress theme The Really Simple SSL WordPress plugin mentioned above handles this redirect for you.
If you’re site redirects non-www traffic to the www version or vise versa, make sure to update these redirects too, so you don’t end up with double or more redirect steps. You can set this up in google webmaster tools. If you are running a WordPress Theme make sure you are changed In WordPress > Settings > General > Update the “WordPress Address (URL)” and “Site Address (URL)” to be https:// instead of http://

Check common files use HTTPS
Most sites have a couple common files such as robots.txt & sitemap.xml. Check to make sure these redirect to HTTPS versions and references to URLs inside the files all also use HTTPS.

Update any canonical & or url references
Often sites use canonical links in theof pages to point to the correct URL for a page, e.g. if multiple URL’s reach the same page in your site these are important. It’s worth checking if your site uses these and that it points to the HTTPS version. At the same time, you should check theof your site. Most times site that use these are using a platform that auto-generates them, so if you check just a couple pages you should be safe that this will be ok on all pages.

Update 3rd party scripts, analytics & other links.
Some 3rd party tracking sites require you either update the tracked origin URL or set up a new account for monitoring.
Here are a few examples, but worth doing a quick audit of any 3rd party tools you use:

1. Google Search Console (Webmaster Tools) – Requires you set up a new account, this allows you to monitor traffic still in Google‘s index hitting the HTTP version first vs the HTTPS version of your site. This means any settings including Sitemaps & Disavow files will need to be uploaded to the new
account. While in here, it’s worth running the Crawl > Fetch as Google command in here to test Google can reach the site without any issues.

2. Google Analytics – Requires a URL change in a couple areas:
– Admin > View Settings > Website‘s URL
– Admin > Property Settings > Default URL
– Admin > Property Settings > Search Console > Adjust Search Console >
Link to the new Search Console account

3. Google Merchant Center (Shopping) – Requires claiming the new URL in Business information > Website > Claim your website. You may also want to update your feed URL if you use this method to regularly import your products.
This is done in Products > Feeds > Select feed > Schedule > Edit Schedule > Update the File URL

4. Google Adwords – Update any Ad URLs to use HTTPS

5. Bing Webmaster Tools – Like with Google, you’ll need to create a new account for the HTTPs version of your site. It’s worth reviewing your site for more of these as some might need updating such as: Disqus comments (https://woorkup.com/migrate-disqus-comments-https/) which uses the current URL as the page the comments are tied to. As well as 3rd party Ads on sites like Twitter & Facebook.

Last step, purge caches
Purge any caches, you may have had to do this earlier on to test content, but it’s worth emptying/purging any internal to the platform caches and any CDN cache etc. to make sure all content is up to date with your changes.

3.Post-Move

Wait for a day or preferably a week. If you’re using CSP, this is a great point to check reports and fix any issues, this can be an ongoing process. Fix the issues found, such as any SSL issues reported, redirect issues or mixed content warnings and then proceed to following steps.
Check your monitoring Analytics, Webmaster tools etc. Here you may notice things like people still hitting the old HTTP pages if your redirect isn’t setup correctly.

Implement HSTS (HTTP Strict-Transport-Security)
One of the main reasons to wait a day or so is to make sure you don’t need to back out of this.
With HSTS you can tell browsers when users visit your site to only request from the HTTPS version of the site, no interactions over HTTP. All that’s needed for this is to add the “Strict-Transport-Security” to your site with
a max age set to 6 months in seconds (15768000)

Inside your .htaccess file, add: Header set Strict-Transport-Security "max-age=15768090;"

More information about this protocol can be found here.
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) For WordPress users. The Really Simple SSL WordPress plugin mentioned above handles setting this up for you.

Plan for when the certificate expires
You should make a note of when your certificate expires on a calendar to be safe. Even if you’ve set up automatic renewal of the certificate, you still need to be sure that it works. Better to test yourself than have a customer call up and point it out to you. With other SSL providers, they normally email you before renewal, but it’s still best to be safe and keep track of this date yourself.
Consider also making notes on how you installed the certificate previously for your future reference.

4. Going above and beyond

Update internal links in pages, emails etc. Even with a redirect from HTTP to HTTPS setup, it’s best to minimise temp HTTP redirects as these can still lead to exposing what the user was doing. To ease the pain of this, if you have access to the code and/or the database, you could run a find and replace overall content for href=”http://yoursite. com” with href=”https://yoursite.com”

Update links on social media etc. Though you’ve set up all your redirects, it’s still best to try to send users direct to
the HTTPS version without the need to go through these redirects. Aim for A+ on SSLLabs (https://www.ssLLabs.com/ssltest) will give you useful information on your SSL/TLS implementation, and any issues found. It’ll also give you recommendations to improve it if any are noticed. This is within reach especially if you’ve set up your HSTS header in the post-move stage.

Consider preloading your HSTS
If you’ve previously set up your HSTS header, you could now opt to preload this into browsers before users even get to your site. To do this, visit the HSTS preload list (https://hstspreload.org/) site to submit your site.

Iron out other similar security actions
Similar to SSL test earlier, this report will show some other recommendations such as use of secure cookies: Security Report. (https://httpsecurityreport.com)

Enable HTTP/2 support
Now that you’re on HTTPS, you can benefit from the speed improvements that come from HTTP/2 on your server and/or CDN.

Consider Brotli compression
Now you’re on HTTPS you could consider Google’s new Brotli compression. They have seen considerable savings on the play store from implementing it. To install on Apache2, you can follow this guide (https://giyeshmegpache-brotli1.

Footnote:
The content provided within is a resource to aid migration only. By following it by no way leaves the project or its authors liable. Every site is different and depends on your level of experience. What may work for some may not work for others as there are many elements beyond this guide. We recommend seeking professional advice before commencing your site migration.