One of my visitors recently told me that he wanted to convert his website from HTTP to HTTPS and wondered if I could write an article on the things he needed to watch out for. This article weighs the pros and cons of moving a site to SSL and provides a checklist of some things you need to remember to do.
To make sure we are all on the same page here, I will use "SSL" to collectively refer to the Secure Socket Layer certificate (or SSL certificate), and its successor, the TLS ("Transport Layer Security") certificate. Such certificates allow visitors to access websites with URLs (web addresses) that start with "https://" instead of the usual "http://". They are obtained from a Certificate Authority ("CA" for short), which may be a commercial entity like GoDaddy (or any of the other domain registrars and even some web hosts), or one of the free certificate authorities like Let's Encrypt.
SSL certificates are not only useful for sites with order forms where users have to enter their credit card numbers, but normal sites too. While it's true that the former must have SSL, the cert also has benefits for a website that doesn't have a shopping cart.
When you connect to a site like (say) https://www.thesitewizard.com/, the Certificate Authority certifies that you are indeed connected to thesitewizard.com, and not some other site pretending to be thesitewizard.com.
Without SSL, there is no guarantee that what the browser says on its address bar is true, since it's possible that somone has intercepted your request and has given you a web page belonging to some scammer. The browser will not know that the site displayed is not the one stated in its address bar. This is known as a Man in the Middle attack, or one form of it.
On the other hand, if you connect to a site via HTTPS, and the browser says that the connection is secure (ie, a proper padlock icon is shown and not one that is broken, crossed out or missing altogether), and the Certificate Authority is the same one that the webmaster used for his/her certificate, then under normal circumstances, chances are that you are indeed connected to the site shown in the browser's address bar.
You can test this out with thesitewizard.com itself. The padlock icon on the address bar should be intact, not one that is broken, crossed out or missing. If you use Firefox, hover your mouse over the padlock icon to find out the name of the Certificate Authority. (Do the equivalent for your browser if you use a different brand. Browsers serious about security should make it easy for you to view this, since having this information is part of what makes a site secure.) The certificate should show that it's verified by Let's Encrypt, one of the free certificate authorities around.
If any of these things is not true (the padlock and the name of the Certificate Authority), it means you are a victim of a Man in the Middle attack. Note that it may not necessarily mean that some nefarious criminal organisation is after you. Certain computer manufacturers and antivirus software have been known to compromise your security by installing their own certificates on your machine, certifying every site as legitimate even when they are not. In such a case, you can no longer trust the "https://" prefix and padlock in any browser on your computer since you may not be connected to the site you think you are.
Some of you may be wondering why I qualified my sentence a few paragraphs back to suggest that even when everything is correct, you still don't have 100% assurance. The problem lies with the system being dependent on the Certificate Authorities being both competent and trustworthy. Unfortunately, there has been a history of problems with this, with a few of them not doing things properly, and approving certificates for people who don't have the right to it. For instance, I vaguely recall one famous case where a CA issued a certificate for google.com to someone who had no right to it. In such a case, that entity or person could potentially pretend to be google.com to anyone in the world, harvesting logins and passwords to Google's many Internet properties and no one will be the wiser. Another case is mentioned on my free SSL certificates page for a different company. And there have been other incidents before these.
I probably don't have to say much about this point, since everyone seems to know that when your connection is over HTTPS, the browser encrypts its communication with the website you're connecting to.
This is particularly important if the site either collects credit card numbers, or requires users to log in with a password. Without the communication being encrypted, not only will anyone on your network and your Internet provider be able to eavesdrop on what is being sent back and forth, but all the machines on the electronic route between your Internet provider and the website will also be able to do the same.
Since your connection is encrypted, the content you see should be what the webmaster has intended you to see.
If you are thinking that this doesn't affect you, since your site is not some vital site affecting the fate of the world that people may want to modify, consider this: there are some Internet Service Providers (ie, companies providing broadband, WiFi or dialup services) that insert their own advertisements into the pages of the sites their customers visit. These advertisements appear as though they are the site's own adverts.
With SSL, Internet Service Providers should (theoretically) not be able to do this since your page content can no longer be modified by them (being encrypted and all). And if you also implement the frame blocking facilities introduced by Internet Explorer (and now supported by the other major browsers), they will not be able to put your site in a frame with their advertisements in the outer frame (frameset).
With SSL, the specific pages within your website that a visitor goes to will no longer be sent openly, in plain text, by your web server. While this is not important for a tutorial site like thesitewizard.com (or indeed any of my sites), it may be for others where the URL itself may reveal crucial information.
Nowadays, browsers label websites that do not use SSL as either "Not secure" (Chrome) or with a broken padlock icon (Firefox), even if the website does not contain a form. Changing the site to use HTTPS avoids it being labelled as such.
Google's representatives have also said that in a situation where two websites have the exact same ranking, the HTTPS site will be displayed in the search results before the other one. This initially led to a bunch of sites rushing to convert to SSL, but the fever died down when everyone discovered that such a situation was so rare (if it even ever surfaces) that moving to SSL made no difference whatsoever to their search engine performance.
Very old browsers, including Internet Explorer 6 (and possibly 7) and some very old Android browsers, will no longer be able to successfully connect to your website. Those browsers do not support the newer forms of encryption that modern SSL sites use.
That said, before you think that this is a significant problem, those browsers are mostly extinct, these days. You should check your own web statistics if you're concerned about this. In fact, according to usage statistics from Mozilla (the makers of Firefox), at the time I write this paragraph, about 80% of sites encountered by their users have SSL. Assuming that this roughly translates to the number of SSL sites the average surfer encounters, it means that even if there are people still using the old browsers, they will be accustomed to not being able to connect to most websites today, and will probably have a modern browser to use as a fallback.
Some types of SSL certificates have no free equivalent.
If you want to use one of those special certificates that used to show up in a browser's address bar with the organisation's name next to it in green (called "EV certs", where EV stands for Extended Validation), you will need to buy a commercial cert. (I say "used to" because the current versions of Firefox, and possibly also Chrome, no longer distinguishes between this certificate and the regular one.)
For the curious, the free certificates only confirm that you are connected to the domain name stated in the browser's address bar. The EV ones also certify that the domain is indeed owned by the organisation mentioned in the cert. Note though that this doesn't mean that the organisation is what you think they are. For example, it's possible for scammers to get certificates for their domains with an organisation name that seem similar to the one they are spoofing. The problem is exacerbated by browsers (namely, the iPhone's Safari, at the time I write this) that don't show the URL (web address) of a website if it has an EV cert, making it easier for their users to be scammed. For example, if a scammer has registered, say, a company named "PayPal Services International" and has a website with an EV cert, the browser in question will only show "PayPal Services International" at the top, and not the underlying URL. Users who don't know that the PayPal site is registered by a company called "PayPal, Inc" will be fooled, since they cannot use their usual method of examining the URL for clues. And you cannot realistically expect the average user to be a walking encyclopedia of company names.
If you don't use an auto-renewing certificate, then you will have to add the cert to the list of things you have to remember to renew.
The move to SSL carries with it some risk, since you are actually changing the URL of every page of your site. As such, webmasters are correct to worry that it might cause their traffic to dip.
That said, Google's representatives have implied that their engine can handle the transition without affecting your site's status. My sites didn't seem to encounter any such problems when they moved, but I'm not really sure about this, since I didn't analyze my web statistics in any detail.
As for Bing, since I don't normally monitor my traffic from that source, I don't know if my traffic from them was affected.
Moving to SSL requires you to do a number of things over and above your usual work. If your site doesn't actually need SSL (eg, you have no order forms), and it is already well-established in its HTTP form, it can be easy to keep putting it off, since it's a lot of extra work for, at best, very little gain.
If you have a big site that is mission critical, you may be worried about moving the whole site to SSL in one go. Moving in stages allows you to test the conversion process, and learn from the mistakes made before it affects the rest of the site. This is especially so if it is the first time you are converting a site to HTTPS.
It was also what I did with thesitewizard.com, which was the first major site I moved to SSL. While it did help me iron out some small wrinkles here and there, such as allowing me to spot places where I forgot that I needed to update (one of which is my internal site search form), in hindsight, I don't think the staggered conversion was really necessary here. In the end, after a few stages which only covered about half the site, I got tired of the process and just moved the rest in one fell swoop.
For thefreecountry.com and howtohaven.com, having learnt from my experience with thesitewizard.com, I did everything in one go.
For the kind of sites that I own (information resource and tutorial sites), I found that converting the entire site to SSL in one step was less work, allowing me to get everything working smoothly together instead of having to coordinate between the HTTP and HTTPS sections.
Where the search engines are concerned, I didn't really notice any difference in effect between the two methods.
Note that if you don't have a website yet, and are planning to have one, it is probably a good idea to use HTTPS from the very start. It's what the whole of the Internet is moving towards, so chances are that you will end up doing it sooner or later. Using SSL for your site from the very start will save you the hassle of having to convert things later on. If you are in this boat, you only need to follow my first point below while carrying out the other steps given in How to Create a Website.
As mentioned earlier, an SSL certificate can be obtained from many places, such as from one of the domain registrars that sell it, or from a free certificate authority. You can even generate one yourself, on your own computer.
You may not even need to get a certificate from an external source. Many web hosts (like DreamHost) provide it free of charge. Note that I'm not going to list all the web hosts that provide this service, since you can just check them out for yourself. (I don't want to have to keep updating this paragraph, since I'm sure more and more web hosts will include it in their packages over time, if only to remain competitive.)
Incidentally, if you are considering getting the free Let's Encrypt certificate like I did for thesitewizard.com, you should probably only go for it if you have a web host that supports its automatic renewal. Unlike the commercial SSL certificates, which are valid for 1 to 3 years and so only needs to be renewed once in a long while, the Let's Encrypt certificate requires frequent and repeated attention. Specifically, it expires every 90 days, and requires you to run special software to get it updated and installed. It's not only a hassle, but even if you manually generate the Let's Encrypt certificate yourself, you will still need access to the web server configuration files to install it. Web hosts that support it run a computer program on their end that does everything automatically, including renewing the certificate when it's near the expiry date and installing it, which is why I said that you should only use it on such hosts. In the latter case, once you enable the certificate, you don't have to worry about its renewal again.
For those who bought a commercial cert, you will have to ask your web host to install it. An SSL cert is not something you can normally install yourself, unless your site is on a dedicated server or the like. You will probably have to send it to their support email address. That said, a number of shared web hosts these days allow you to install it via your web hosting account's control panel.
Search for all instances of "http://www.example.com" and replace them with "https://www.example.com" (where
www.example.com refers to your domain) on the pages of your site (including your
404 and other error files,
if you have them). Remember to do the same for scripts that embed your URL
(such as your contact form script, including the one generated by the
Feedback Form Wizard)
and any other types of files (such as XML files) that you may have.
If your web editor lacks the capability to search and replace across multiple files in one go, use a specialized search and replace tool. I personally use a commercial program called PowerGrep but there are numerous free ones listed on Free Text Search and Replace Utilities page which will also do the job.
If you have the habit of sometimes referring to your site as "http://www.example.com" and other times as "http://www.example.com/" (with a "/" at the end), remember to search for "http://www.example.com" and not "http://www.example.com/". The former will catch all instances of your URLs, while the latter will miss those addresses that don't have the final slash. And if you also sometimes link to your site as "http://example.com", without the "www", remember to replace those instances too. Incidentally, you should ideally standardize on using either the "www" form or the plain domain name form.
You should still perform the above search even if you normally use relative links (ie, links like "some-page.html" instead of "http://www.example.com/some-page.html") to refer to your internal pages, in case there was an occasion in the past where you absent-mindedly used the full URL.
If your site is not a static site, created with a web editor, but is instead managed by a content management system (or CMS) or a blogging program, you may have to update your URLs from within that script's interface. You may also need to manually modify its configuration file to get the software to realize that you have changed web addresses, and possibly even do a search and replace in its database.
Now search for all instances of src="http://. In fact, you may even need to search for
their equivalent, like src='http:// or src=http://.
This is to catch embedded images,
videos and audio
files with external sources, that is, resources which you embed on your site but are hosted elsewhere. You will have to
change those URLs to their https equivalent. For example, if you have linked to thesitewizard.com (or
any of my sites) using a button or banner from my Link
to Us page, you should update the code to use the "https" equivalent.
What happens if the site hosting the resource does not have an HTTPS version of the URL? One way is to ask the original site if they will allow you to host the image, video or audio yourself. Alternatively, instead of embedding the object on your site, you can just use a normal text link to point your visitors to the external site where they can view it directly.
Leaving an embedded image, video or audio file linked to without HTTPS will lead to your page having a broken padlock icon (or its equivalent) in your visitor's browser or perhaps not even having a padlock icon altogether. It's possible also for some browsers to completely block that resource from loading. (How it is handled depends on the browser, and in fact, even varies from version to version of the same browser.)
Similarly, if you have a form where the action attribute points to a "http://"
resource, you will also have to replace those with their HTTPS equivalent, if available. Obviously if all
your scripts are hosted on your own site, you will not need to take this step since those URLs will already
have been updated when you changed all your internal links. It only applies to forms invoking
remotely hosted scripts.
Another thing to look out for are the externally hosted JavaScripts that your site may use. You may not think of them as JavaScripts, but some facilities provided by other websites for use on yours are delivered via JavaScript. This includes advertisements (including Google AdSense), embedded videos, web statistics, some CAPTCHA tests, and many more. There is even one web font service that delivers its fonts via JavaScript.
Besides JavaScripts, you should check for any other resources loading on your web page that is hosted elsewhere. This includes Cascading Style Sheets (such as those used by some web font services) and other types of embedded objects.
So that you don't get confused. I'm not referring to normal links to other sites here. Those can be either "http://" or "https://". It doesn't matter, since they do not load things from those sites on your page. Only things that actually get loaded on your page need to be changed. They need to be delivered using HTTPS like your page.
If you have a search engine sitemap using the Sitemap protocol (note that I'm not talking about a Site Map that is designed for humans, but the XML one meant for search engines), update all the URLs there (unless it has already been updated in your first step).
Remember also to change the link in your robots.txt file so that it refers to your sitemap file using HTTPS.
If you have lines in your .htaccess file to prevent others hotlinking your images and other files,
you will need to update them to include your SSL URLs. Otherwise the pictures will no longer load on your site.
For example, if your code is based on the sample I gave in my anti-hotlinking article, you will have to modify it as follows:
Remember to change all instances of www.example.com and example.com to your domain.
If you are not sure what the above code does, please read the original
hotlinking guide
(which has been updated to include the SSL versions of the URLs).
When you are done, upload your site and test it in one or more of the major browsers (Chrome or its derivatives, Firefox, Internet Explorer and Edge).
If you don't see the padlock icon, or it's a broken padlock or some such thing, it means that your web page has loaded some element with "http://" instead of "https://". Go through the HTML source of the page and make sure all forms, images, embedded videos, CSS, JavaScripts, etc, are loaded with "https://".
Note that you should not just test one page and assume that everything is fine with the rest of your site. If different pages on your site have different elements, you probably should at least check a representative of each type of page.
Once you are sure your site works fine under SSL, you can redirect people who go to the HTTP version of the site to its equivalent HTTPS page.
This is optional, and there are pros and cons associated with doing it.
Not automatically directing people to the HTTPS version has the advantage that people who cannot load the SSL version (eg, those who use obsolete browsers) can still use your site.
Automatically redirecting has even more advantages: it tells search engines that the URLs on your site has moved in a way that tranfers the rank of the old page to the new. People accessing your site will also discover the availability of the SSL version and will automatically use it. In addition, Internet service providers cannot force their customers to use your HTTP version and then modify the content on your page to add their advertisements (or whatever).
To automatically redirect, you will have to modify your server configuration. If your site is
hosted on an Apache server (version 2 and above), add the following lines to the .htaccess file
in the root (ie, topmost) web directory.
If you don't have a .htaccess file there, create one using a
plain text
editor (also known as an ASCII editor). Windows users can use Notepad found on their system, although if
you do, remember to save your file as ".htaccess" (including the quotation marks) otherwise
Notepad will
change the filename to ".htaccess.txt" behind your back.
If there is already a "RewriteEngine on" line in your existing .htaccess file,
do not add the one given in my code. Only one "RewriteEngine on" line is sufficient to enable the
module that handles such rules. In such a case, add these rules (minus the first line) after
your existing .htaccess lines.
The .htaccess given above causes the server to check if there is a variable called "HTTPS" with the value "on". This variable is automatically set to "on" if the visitor connects with HTTPS, and to "off" otherwise. If the test fails (ie, the value is not "on", implying that HTTP was used), it changes the URL so that it begins with "https://" and redirects the visitor there.
If your website is on a server running Apache 1.x (where "x" is some series of numbers and dots), you may have to use the following code instead. Note that the following should also work on Apache 2.x (if your site is configured in the standard way, which it probably is, if it is hosted on a normal shared web host).
The above causes the server to check if the visitor connects to the server at port 80, which will be the case if HTTP was used. If so, it changes the URL so that it begins with "https://" and redirects the visitor there. We have to do it this way because, as far as I know, the "HTTPS" variable is not set on Apache 1.x.
Don't worry if your web host gives you a different set of directives to use in your .htaccess.
There are many ways to do this, including checking if the HTTPS variable has the value of "off",
looking to see if "http://" occurs in the URL, and probably others. They all have the same end result. If in doubt,
just use the code your web host gives you.
If your site is hosted on a different web server (that is, not Apache), you will need to ask your web host for how you can implement this. The above code only works on an Apache server with the mod_rewrite module enabled.
In addition, if your .htaccess file has lines
redirecting
users from your plain domain name to its www version (or vice versa) (eg, from example.com to
www.example.com), remember to change the redirected form to "https://". This is optional, but
if you don't, and your visitor goes to (say) "example.com", he/she will first be redirected to "http://www.example.com" and
then, immediately after, to "https://www.example.com". It's not really a big deal, but it will save one step of redirection.
If you have a Google Search Console account or a Bing Webmaster Tools account, or both, it won't hurt to update them with your new URLs. You may have to submit the HTTPS version of your site as though it's another site and do the verification for it (to prove you are the webmaster).
That's it. You can now sit back and enjoy looking at the padlock icon on your web pages.
Copyright © 2017-2022 Christopher Heng. All rights reserved.
Get more free tips and articles like this,
on web design, promotion, revenue and scripting, from https://www.thesitewizard.com/.
Do you find this article useful? You can learn of new articles and scripts that are published on thesitewizard.com by subscribing to the RSS feed. Simply point your RSS feed reader or a browser that supports RSS feeds at https://www.thesitewizard.com/thesitewizard.xml. You can read more about how to subscribe to RSS site feeds from my RSS FAQ.
This article is copyrighted. Please do not reproduce or distribute this article in whole or part, in any form.
It will appear on your page as:
How to Move Your Website to SSL/TLS (ie, Convert from HTTP to HTTPS)
