Moving to HTTPS Guide

This guide is for moving {{ platformText }} sites hosted with {{ hostingText }} to HTTPS. This guide is for moving sites using {{ hostingText }} to HTTPS - Use the above filters to suit your needs.

For GitHub Pages with custom domains, you can now use HTTPS either via GitHub (read more here) or you can use Cloudflare to proxy the HTTPS. (read more here). Once setup follow the rest of this guide for further setup.
Also if you don't use custom domains, GitHub has a guide for this here.

Outline

1. Pre move

   Before actually moving you'll want 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, setup 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

   For the A+ students, fixing further issues & similar security improvements.

Pre move

1. Select an SSL certificate

   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).
     • Caddy has this built in for free with it's automatic HTTPS feature!
     • Free via Let's Encrypt & Cloudflare, or purchase available.
     • Normally issued in minutes.
   • Organization Validation (OV)
     • Shows organization within certificate but largely appears the same as DV.
     • Requires purchase.
     • Can take several days to issue.
   • Extended Validation (EV)
     • This used to show the organization in URL bar however this is no longer the case.
     • Requires purchase, more expensive.
     • Can take up to a week to issue.

   With Cloudflare, you get free DV certificates, however they do not allow use of custom certificates unless you use their Business ($200 a month) plan.

   For most sites, DV certificates are exactly what you're looking for.

   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 setup each subdomain separately.

   If you're just looking to secure your main domain a 1 or 2 DV certificates will work perfectly.
   Free DV certificates are available with Cloudflare
   Many sites such as SSLs.com offer certificates.

   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 organization's existence. But if you're selecting a DV certificate then you can wait till the moving day.

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

   Cloudflares free certificate covers multiple subdomains but wildcard support is restricted to their Business plan. The certificates also do not support old browser/OS combinations such as Windows XP or OS X 10.5 or less.

   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 which could.

2. 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. You can check whether your hosting provider offers free SSL certificates here. It's worth contacting them to be sure.

   REC offers both free and paid SSL via Let's Encrypt & Cloudflare.

   Wix offer SSL on all sites though currently do not allow you to install custom certificates, but you can also use Cloudflare to provide this.

   At the time of writing this, Weebly only support SSL on the Business+ plans and do not yet support custom SSL certificates. However you should be able to use Cloudflare to get around this for free. Find out more here

3. Do you have a test site?

   This is optional as most sites don't have access to a test site, nor will many sites actually require one anyway.

   But if you are able to, making these changes on a test / staging version of your site first would reduce the risk that comes from editing a production site.

4. 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 much less time, but it's worth having that spare time just in case.

5. 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.

6. How will you track changes?

   In the event that the migration causes some short term disruptions in traffic and/or search rank, you'll want stats to fall back on and provide visibility of what exactly changed.

   If you haven't already, setup Google 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 (Webmaster tools) setup 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.

7. 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 'til you first have SSL installed.

8. Do you plan to move your entire site or just specific areas first?

   If you can, moving 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.

   However, not all sites are able to do this at one, 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.

   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 fro 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.

Moving day

1. Get the 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 installing it.

   Caddy comes with free HTTPS via Let's Encrypt without you having to do a thing. To use you can skip ahead to step 3. But if you want to buy a certificate (e.g. an EV certificate) you certainly can use that instead.

2. Install the certificate

   If your installing a custom certificate to your Caddy server, all you need to do is reference the new certificate and private key file in your Caddyfile like so:
   tls ../cert.pem ../key.pem
   More details here.

   Inside your cPanel account > SSL/TLS Manager > "Generate, view, upload, or delete SSL certificates" > "Upload a New Certificate" > paste or upload the .crt file here & click Upload.
   Click Go Back > Return to SSL Manager > Setup a SSL certificate to work with your site > Select the domain & this should fetch the certificate & key for you, but if this option doesn't show or doesn't work you may need to contact your hosting provider / support. Under the certificate & key there should now be a 3rd box for Ca Bundle where you'll need to paste you bundle file. Click Install Certificate & your done.
   Now you just need to restart Apache for it to take effect.

   Inside Plesk > Hosting Services > Domains > Find the domain you want to setup SSL for and click "Control Panel" > Websites & Domains > Secure Your Sites > Under "Certificate name" find the certificate you previously setup. Upload the Certificate / .crt file, and upload the CA certificate / bundle file, then click "Send File". Back to the Websites & Domains > Check that "Enable SSL support" is selected & then select your certificate from the menu, Click OK and you're done.
   Now you just need to restart Apache for it to take effect.

   For REC, please contact support for them to install the new certificate for you.

3. Check the certificate

   First check, before any others, load the site up in your browser (make sure to load the HTTPS version).

   It may take a few minutes for Cloudflare to provision your certificate. You can check on this progress in the Crypto tab > SSL > under the drop down it will say "Active Certificate" once complete.

   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 can be used here to check and diagnose the issue.

   If needed, this article 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.

   On REC if the site does not load over HTTPS at first, check Admin > Redirect Manager for any redirects that may have pointed away from HTTPS.

4. Find mixed content

   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. 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:

   1. Using a tool to externally crawl over your site at once.
      These crawling tools work with any site as they are run externally. Here are some examples:
      • HTTPS Checker is a desktop app (available on Windows, Mac OS X & Ubuntu Linux) to crawl a site for mixed content and related issues.
      • Mixed Content Scan by Bramus is a command line php script that will crawl a given site for mixed content issues.
      • SSL Check by JitBit offers a quick online tool to find mixed content - though is limited to 200 crawled URLs.
   2. Automatic replacing content live as it's sent from Cloudflare to users browsers with "Automatic HTTPS Rewrites" - This is an experimental new feature inside Cloudflare that replaces links to HTTP resources with HTTPS where possible, though you may still have content that loads over HTTP is a HTTPS version isn't available, but this can certainly ease the pain.
      • Read more here
   3. There are some WordPress 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.
      • Really Simple SSL
      • SSL Insecure Content Fixer
   4. 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.
      

   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.

   To fix any issues found in Blog post older reference blocks run: Admin > Blog Settings > "Fix Mixed Content Reference Blocks".

   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 a 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). You can read more about this here. This is probably the nicest way to do it, but requires the resource actually have a 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 that, so using this with the reporting services above would be wanted.

   To test, recheck your site with the tools used in the previous step.

6. 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 that 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 down too.

7. 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.

   Luckily Caddy takes care of this for you, just test it works and move along.

   In PHP you could do this like so: if ($_SERVER['HTTPS'] != 'on') { header('Location:' . 'https://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']); exit; }

   In ASP.NET you could do this in your web.config file like so: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="HTTP to HTTPS redirect" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </rule> </rules> </rewrite> </system.webServer> </configuration> Ref: https://www.hanselman.com/blog/HowToEnableHTTPStrictTransportSecurityHSTSInIIS7.aspx

   In Node.js using express.js you could setup middleware to detect if the request is secure and if not then redirect to the HTTPS version. Or you could use pre-built package such as `express-http-to-https` like so: npm install --save express-http-to-https and then to use it like so: app.use(redirectToHTTPS());

   In Python Flask you could do this like so: @app.before_request def before_request(): if request.url.startswith('http://'): url = request.url.replace('http://', 'https://', 1) code = 301 return redirect(url, code=code) Ref: https://stackoverflow.com/questions/32237379/python-flask-redirect-to-https-from-http#answer-32238093

   In Ruby on Rails you could do this like so: # config/environments/production.rb Rails.application.configure do # [..] # Force all access to the app over SSL, use Strict-Transport-Security, # and use secure cookies. config.force_ssl = true end Ref: https://stackoverflow.com/questions/1662262/rails-redirect-with-https#answer-26382183

8. Change platform settings

   In WordPress > Settings > General > Update the "WordPress Address (URL)" and "Site Address (URL)" to be https:// instead of http://

   In Joomla > System > Global Configuration > Server > Force SSL > Select Entire Site

   In Wix > Manage Site > Click Manage next to SSL Certificate > Turn on SSL

   In your Weebly settings there should be an SSL option which you can switch to "Entire Site".

   To set an entire Drupal site to HTTPS no config changes are needed, but to support partial site HTTPS Drupal may require a config change or installation of the Secure Login module. There's more details on this here.

   In Magento > Admin > System > Configuration > General > Web > Secure > Select Yes for "Use Secure URLs in Frontend" & "Use Secure URLs in Admin"

   In Shopfiy > Admin > Online Store > Domains > SSL certificates > click "Activate SSL certificates"

   In REC > Admin > Site Settings > Security > click to "Use SSL" and for entire site HTTPS also tick "Use SSL Everywhere", we'll come back to the 3rd setting later on.

   In Github > Find your repository page > Settings > Find the "GitHub Pages" section & select "Enforce HTTPS".

   Check if your platform/site has a settings area for the default URL or a switch for using SSL.

9. 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.

10. Update any canonical & og:url references

    Often sites use canonical links in the <head> of 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 that it points to the HTTPS version.

    At the same time you should check the <meta> of 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.

11. 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's a few examples, but worth doing a quick audit of any 3rd party tools you use:

    • Google Search Console (Webmaster Tools) - Requires you setup 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.
    • 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
    • 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
    • Google Adwords - Update any Ad URLs to use HTTPS
    • 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 you might not expect need updating such as: Disqus comments which uses the current url as the page the comments are tied to. As well as 3rd party Ads on sites like Twitter & Facebook.

12. 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.

Post move

1. Wait a day or maybe 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 in Analytics, Webmaster tools etc. Here you may notice things like people still hitting the old HTTP pages if your redirect isn't setup correctly.

2. 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)

   The Really Simple SSL WordPress plugin mentioned above handles setting this up for you.

   Drupal can offer this via the Security Kit module.

   You can enable this in REC by ticking the "Use Strict Security" in Site Settings.

   Inside your nginx conf file, add the following inside the server block: add_header Strict-Transport-Security "max-age=15768000;";

   Inside your .htaccess file, add: <IfModule mod_headers.c> Header set Strict-Transport-Security "max-age=15768000;" </IfModule>

3. 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 setup 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 self to reference.

Going above and beyond

1. Update internal links in pages, emails etc.

   Even with a redirect from HTTP to HTTPS setup, it's best to minimize 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 over all content for href="http://yoursite.com with href="https://yoursite.com

2. 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 need to go through these redirects.

3. Aim for A+ on SSLLabs

   SSLLabs 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 setup your HSTS header in the post-move stage.

4. 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 site to submit your site.

5. 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.

6. 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.

7. Consider Brotli compression

   Now you're on HTTPS you could consider Google's new Brotli compession. They have seen considerable savings on the play store from implementing it.

   There's an nginx module that you can compile to add brotli support.

   To install on Apache2, you can follow this guide.

Disclaimer: This site is provided under the MIT licence and available on GitHub. All content is provided as a resource to aid migration only. Following it in no way leaves the project or it's authors liable.

Found an issue or want to contribute changes? Fork us on GitHub or open an issue.