I’ve recently decided to move askupasoftware.com to using a secure SSL connection. I’ve heard that Google was starting to use HTTPS as a ranking tool, and I couldn’t let that hurt my rankings. Since askupasoftware.com is a multisite – this process was a bit more complicated. On top of that, I had some redirection issues since the website was using a proxy. My goal was to have the site work properly without installing any additional HTTPS-enforcing plugins. I couldn’t find a comprehensive guide that explains how to complete this process for a setup like mine, so I’ve decided to share my notes with you in hopes that it will help anyone who runs into similar issues.

What is HTTPS?

HTTPS is the secured version of the HTTP protocol. The ‘s’ in HTTPS stands for secured. Using HTTPS, all communications between the browser and the server are encrypted, making the data protected against eavesdroppers. The purpose of HTTPS is to ensure the privacy and integrity of the data being transferred. It also gives your visitors a way to verify that they are visiting your website and not that of an impostor. Certain browsers like Google Chrome, Safari & FireFox show a green padlock icon to the address bar when a website is using a secured HTTPS connection.

HTTPS lock icon in Google Chrome for askupasoftware.com

Why should I use HTTPS?

There are various benefits for using HTTPS over HTTP. The main benefit is the security of the data being exchanged between the client and the server. If you exchange sensitive information, like credit card numbers, this is a must. Additionally, customers are more likely to give their credit card information to a site that’s using an encrypted connection. However, even if you don’t transfer sensitive information, and even if you don’t sell anything online, it is still a good idea to use HTTPS since it can slightly increase your organic search ranking in Google.

Getting an SSL certificate

Also known as CA Certificate, an SSL (Stands for Secure Sockets Layer) certificate is a digital certificate issued by a certificate authority (CA) to a validated entity. There are commercial certificate authorities (like VeriSign) as well as free certificate authorities (like Let’s Encrypt), each with its own set of benefits.

There are also certain CDN providers that offer free SSL. One of them is CloudFlare. CloudFlare provides a way for you to easily use SSL in your websites without having to get a CA Certificate or install anything on your server. When using a CDN, the client is connected to your server through a proxy. If you use CloudFlare’s Flexible SSL option, you can have CloudFlare secure the connection between their servers and the client’s browser. Although the connection between your server and CloudFlare’s servers remains insecure, the client’s browser is not aware of that and the green padlock icon will be shown in the address bar nevertheless. You can use the more secure option of Full SSL, however this option requires you to install SSL on your server, which is not always possible (if you are on a shared hosting plan, for example).

CloudFlare’s different SSL options

Forcing the Administration to use HTTPS

To force all the pages in the admin dashboard to be served via HTTPS, you’ll need to modify your config.php file and add the following constant:

define('FORCE_SSL_ADMIN', true);

Without adding that constant, your admin dashboard will not be served over HTTPS, which can lead to issues as the browser may try to block it.

Changing the site URL

When using HTTPS, the site must be entirely hosted and served over HTTPS, including all static assets. If, for example, a script is loaded over HTTP instead, it can potentially expose the user to attacks (this is only applicable to resources that are loaded from the same host, external resources doesn’t have to be served over HTTPS). Therefore, if you are moving your WordPress site from HTTP to HTTPS, you have to make sure that you change the site URL and any occurrence of http:// to https:// or else your site will not function properly since any resource served over HTTP will be blocked.

In a WordPress based site, this could get a little tricky. The obvious way to achieve this is to change the WordPress Address and Site Address through the admin dashboard (Settings ->General). Unfortunately, doing that is not always enough, since some occurrences of the previous URL may be left in the database.

WordPress General Settings in the admin dashboard. Leaves traces of old URL.

A better approach is to do an SQL dump and do a search & replace manually on the entire database. Unfortunately, this approach creates a serialization problem, as some of the data is stored in a serialized form. But no worries! There is an easy fix for that – simply run this serialization fixing PHP script after you’ve replaced all the URLs in the SQL file and you are good to go! When you’re done, import your modified SQL file to your site’s database, replacing all the original data.

Clean up mixed-content issues

As I mentioned before, when using HTTPS, all the content must be served over HTTPS. Usually, cleaning up the database from any traces of the old URL should suffice, however, sometimes you can find occurrences of the previous URL (the one using http:// instead of https://) hardcoded in your PHP files. The browser will block any resource that is insecure (served using HTTP instead of HTTPS). To see what resources are being blocked by the browser you can open the console. In Crome, it will look like this:

Chrome mixed content HTTPS warning

Then simply go over the warnings and correct each of them manually.

Redirecting all traffic to HTTPS

After you’ve successfully finished setting up SSL on your server, you need to make sure that any HTTP request is redirected to using HTTPS instead. To do that, you need to modify your .htaccess file to handle that redirection. Add the following lines before any other redirection rule in your root .htaccess:

Note that if your server is behind a proxy, and you don’t have SSL installed on your server (If you’re using CloudFlare’s Flexible SSL for example), then you need to handle the X-Forwarded-Proto header as well:

Fixing the ERR_TOO_MANY_REDIRECTS issue

If you are hosting your WordPress site behind a proxy that provides SSL, but the connection between the proxy and your server is insecure (which is the case when using CloudFlare’s Flexible SSL option), then any request that is sent to your server will go into an infinite redirection loop. This is because your request is initially made over HTTPS, but the proxy server “converts” it into HTTP. Since your server is now configured to serve all requests over HTTPS, it redirects any request coming from the proxy server. To fix that, you can detect whether the original request (between the client and the proxy) was made over HTTPS by checking against $_SERVER['HTTP_X_FORWARDED_PROTO']. You can do that by adding the following code to your config.php file:

Note that this will only work if your proxy server is properly configured to set the HTTP_X_FORWARDED_PROTO. CloudFlare has it’s own WordPress plugin that handles that for you without having to add a single line of code.

Let Google know about the change

And the best way to do that is to submit an updated XML sitemap. There are many plugins that automatically generate an XML sitemap for you, such as Yoast SEO and Jetpack. The important thing to note here is that you must add HTTP and HTTPS versions of your site as separate Search Console properties in your Google Webmaster account. Don’t worry – you won’t lose rank for having “duplicate” content.

Be patient. It may take a few weeks before Google re-crawls all the pages in your website.

Conclusion

HTTPS is becoming the preferred protocol for all websites, regardless of the sensitivity of their data. This is encouraged by Google as HTTPS is now giving websites an SEO boost. What once used to be an expensive process, can now be achieved for free with services like CloudFlare and Let’s Encrypt. The entire process may take a few weeks (unless you are starting a brand new website), so be sure to start early. Anything to add? Let me know in the comments!

Edit (9/9/2016)

It appears that Chrome, as part of their efforts to make the web more secure, is giving us another reason to move our sites to HTTPS:

Beginning in January 2017 (Chrome 56), we’ll mark HTTP sites that transmit passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

After the update will take place, non-secure HTTP sites that transfer sensitive information will be marked as “Not Secured” in Chrome’s address bar:

Chrome treatment of non-secure HTTP pages in its first phase

Eventually, Chrome will mark non-secure websites with a red triangle. This will have a serious impact on non-secured websites.

5 comments for ”“

Hi Yoav, nice detailed post, especially about letting google know as many people forget this.
Ref the mixed content issues, you might be interested in HTTPSChecker (httpschecker.net). We have a desktop app (windows, mac & linux versions available) & an online service, they can be used to scan sites for mixed content and similar issues, along with monitoring for issue reports after migration. Hope it’s of use.

Hi Atul,
The main issue with SSL in a multisite environment is that it requires a wildcard certificate. A wildcard certificate allows you to secure the main domain and any of its first-level subdomains (in your case, *.socialsubway.com). This problem is mainly a financial one, since a wildcard certificate is more expensive than a simple certificate (up to 4-5 times more).
Instead of a wildcard certificate, you can also install a different certificate for each domain, but that’s not cheap either and it creates administrative overhead.
If you don’t want to spend too much money on SSL, you can use Let’s Encrypt, or CloudFlare’s Flexible SSL option, both of which are free.