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.

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

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.

Check out your CDN's site to see if there's anything you need to change / be aware of during the migration process.

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.

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.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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 and Let's Encrypt . Many sites such as SSLs.com or SSLmate offer certificates.

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.

For most sites, DV certificates are exactly what you're looking for. But it's worth considering EV certificates as they show the organization in the URL bar.

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.

There are 3 main types of certificates you can choose from for your site:

As most SSL providers now supply a 2048-bit key or higher by default, your first question really is, what sort of certificate do you want?

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. If you're looking to use Let's Encrypt's free certificates and you'll be installing the certificates over SSH then Certbot will walk you through this & setting up automatic renewals. cPanel now offer a plugin that adds let's encrypt support. SSH into the server as root, then just run this command:

/scripts/install_lets_encrypt_autossl_provider



Once installed, Let’s Encrypt will appear in WHM’s Manage AutoSSL interface (Home >> SSL/TLS >> Manage AutoSSL) where you can enable the provider. Plesk now offer a plugin that adds let's encrypt support. Install the Let’s Encrypt extension via the Extension Catalog:

Next, click the installed extension, select a website, and install the certificate. Once the plugin is installed, you should find You may need to ask who runs your server to install the plugin if it's not already installed. If you want to use Cloudflare's free certificates, all you need do is sign up with them and move your nameservers 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 through any 3rd party you will need to generate a Private Key & a Certificate Signing Request (CSR) on your web server. They will only need the CSR but the private key is needed on your server. The site you're purchasing from should guide you through this, but just in case: Inside your cPanel account > Security > SSL/TLS Manager First we need the Private key: Under "Private Keys (KEY)" click "Generate, view, upload, or delete your private keys" > Scroll down and under "Generate a New Key" select the domain & click Generate.

This should now have generated the key, next we need the CSR.

Click "Return to SSL Manager" to go back and this time under "Certificate Signing Requests (CSR)" click "Generate, view, or delete SSL certificate signing requests" > enter the details requested, Host being the domain you're generating this certificate for, Country being the 2 character code e.g. US for United States, then click Generate. This will then show you the CSR which you can copy and paste to the certificate authority you are buying the certificate from. Inside Plesk > Hosting Services > Domains > Find the domain you want to setup SSL for and click "Control Panel" > Websites & Domains > Secure Your Sites > Add SSL Certificate > Enter the details requested & click Request. The CSR should then be available in "SSL Certificates" which you can copy and paste to the certificate authority you are buying the certificate from. Digicert have a useful support page listing multiple platforms & operating systems each linking off to how to generate your CSR.

Also GoDaddy have great documentation on this as well.

These also include generating the private key at the same time. E.g. Digicert offer a OpenSSL CSR Creation which generates a command you can run via ssh which generates both the CSR and private key file.

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. Using the Mozilla SSL Configuration 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 onto that part for now and adding it in later which we will 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. Unless your platform allows you to install the certificate, you will need to contact them and ask to install the certificate for you onto the site's server.

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.

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

Though setting this up usually requires access to the code or to install plugins to your platform so we'll skip this. It's usually a regarded as the more 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's a few examples: HTTPS Reporter - Hosted CSP endpoints specifically for handling mixed content. They provide you with a prebuilt CSP header designed just to catch mixed content issues ready to set up on your site. Great graphs of reports over time & more.

Report URI - Also offers hosted CSP collection + a good selection of tools to build more complex CSP headers.

Caspr the friendly CSP Report Aggregator - 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 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.

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.

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.

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. The Really Simple SSL WordPress plugin mentioned above handles this redirect for you. For Cloudflare you can setup a page rule to redirect all traffic to HTTPS: Page Rules > Create Page Rule > Enter your site like so: http://*movingtohttps.com/* then "+ Add a Setting" and select "Always Use HTTPS". Setup your nginx conf file with the following redirect to HTTPS: server { listen 80; server_name site.com www.site.com; return 301 https://site.com$request_uri; } Setup your .htaccess file with the following redirect to HTTPS: RewriteCond %{SERVER_PORT} 80 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. E.g. http://site.com/info/contact.html redirects to https://site.com/info/contact.html. 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. 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

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.

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

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.