Loan Pricing
Firefox lock icon information for an HTTPS webite.

Why and How to Set Up SSL/HTTPS on Your Web Site

This article was originally published in March of 2015. On November 15, 2016, it was updated with information on newer and easier ways to set up SSL.

Most large website operators are somewhere on the road to implementing Secure Sockets Layer (SSL)–also known as HTTPS–on their web sites, but many small web site operators see no need to go through the effort of converting to SSL. There are fundementally four reasons to make the switch:

  • HTTPS can help end users to identify a spoofing attack.
  • HTTPS can help prevent man-in-the middle attacks.
  • HTTPS web sites will be favored in Google page ranks. This started in 2014
  • Unencrypted sites will start to get visual penalties in Chrome beginning on January 10, 2017, and eventually in search results.

While many web site operators may not feel the need to defend users against spoofing and man in the middle attacks, they will almost certainly feel the need to improve their Google search rank. If this article is too intimidating, just ask your support person or hosting firm for “AutoSSL” and “Let’s Encrypt.” Many hosting firms have both AutoSSL and Let’s Encrypt but do not show this in CPanel; they will gladly charge you for paid domain validation certficates. If you specifically ask, they may install a Let’s Encrypt certificate free, but you have to specifically ask for AutoSSL and Let’s Encrypt certificates. The article is divided into the following sections:

Spoofing Attacks and How SSL Can Help

Spoofing occurs when an attacker imitates your web site and tries to get your customer to enter login credentials that the attacker can then use to log in to your site. The most common form of spoofing occurs in emails, but a less well known but more devastating attack is performed by compromising a domain name server (DNS). Your customer enters your URL in their browser and is directed to the attackers site by the compromised DNS server. A quick search of the Internet will unearth some major DNS compromises:

How will setting up SSL on your website help to protect your users from spoofing attacks? It is easy for a spoofer to download your entire website using wget without breaking in to your site at all. Spoofing SSL certificates for your sites is another matter entirely, and requires a significant and time-consuming attack on your site to get the private key used to create your certificates.

End users for your site should know to look for the lock icon when accessing your site; if the lock icon is missing, or the user is prompted to accept a root certificate, they will know that something is amiss. Of the major browsers, Mozilla Firefox, Google Chrome and Opera have the best user interface for noticing whether or not a site supports SSL. Figures 1 through 4 show how the Firefox browser presents the lock icon indicating an HTTPS connection. Figures 2 through 4 show the information on the certificate that is shown if the user clicks on the various buttons for more information. Figures 5 and 6 show how the Chrome and Opera browsers present the lock icon indicating an HTTPS connection. Figures 7 and 8 show the lock icon presentations in Microsoft Internet Explorer and Apple Safari respectively

All of the figures are shown for the Class 2 certificates that most small website operators will purchase. Some of the browsers handle Class three or Class 2 Extended Validation certificates differently in their user interaces. Since these types of certifications are quite expensive, it is unlikely that small website operators will purchase them; since this article is directed to small website operators, I won’t discuss how browser interfaces handle those types of certificates, but will discuss the various certificate types in a subsequent section.

Converting your site to HTTPS won’t prevent spoofing attacks from tricking your users, but it will give your observant users a way to identify that they have been subjected to a spoofing attack.

Figure 1. SSL on Firefox. Note the lock icon immediately to the left of the URL, in a prominent location where users are likely to notice its absence.
Figure 1.  SSL on Firefox.  Note the lock icon immediately to the left of the URL, in a prominent location where users are likely to notice its absence.

 

Figure 2. Basic certificate information display in Firefox. Firefox shows that the user is connected to the website verified by the certificate provider. Note that this Class 2 certificate does not contain business ownership information.
Figure 2.  Basic certificate information display in Firefox.  Firefox shows that the user is connected to the website verified by the certificate provider.  Note that this Class 2 certificate does not contain business ownership information.

 

Figure 3. Intermediate certification information on Firefox. The next level of display on Firefox shows additional security information about the site.
Figure 3.  Intermediate certification information on Firefox.  The next level of display on Firefox shows additional security information about the site.

 

Figure 4. Certificate details display in Firefox. The final certificate details display shows the class of the certificate (Class 2 in this case) and other details about the certificate, including the name of the business that issued the certificate.
Figure 4.  Certificate details display in Firefox.  The final certificate details display shows the class of the certificate (Class 2 in this case) and other details about the certificate, including the name of the business that issued the certificate.

 

Figure 5. SSL on Chrome. Note the prominent green color and large size of the lock icon immediately to the left of the URL.
Figure 5.  SSL on Chrome.  Note the prominent green color and large size of the lock icon immediately to the left of the URL.

 

Figure 6. SSL on Opera. Note the prominent green color of the lock icon immediately to the left of the URL box.
Figure 6.  SSL on Opera.  Note the prominent green color of the lock icon immediately to the left of the URL box.

 

Figure 7. SSL on Internet Explorer. Note the grey lock icon to the extreme right of the URL box.
Figure 7.  SSL on Internet Explorer.  Note the grey lock icon to the extreme right of the URL box.

 

Figure 8. SSL on Safari. Note the grey lock icon to the extreme right of the URL box.
Figure 8.  SSL on Safari.  Note the grey lock icon to the extreme right of the URL box.

Man-in-the-middle Attacks and How SSL Can Help

Man-in-the-middle attacks are the other major type of attack where SSL and HTTPS can help. In this type of attack, the attacker listens in on an unencrypted connection and captures user ID and password information that can be used to log in to the site at a later date. This type of attack is commonly performed by setting up an open WiFi access point in a public place. Many Internet Service Providers (ISPs) sniff traffic for the web sites that users visit, and insert ads into the datastream based upon the sites that the user visits. A less common version of this attack requires compromising a router and redirecting traffic through a router/server that listens in on the conversation. This very organized attack is more common than most people realize:

A website operator cannot control routing of internet traffic. The ONLY defense against this type of attack is to encrypt traffic between the user’s browser and the web server using SSL and HTTPS. The next section describes the various types of certificates in general, with emphasis on the types of certificates of interest to small business website operators.

What is a Certificate?

SSL is based upon public key encryption and is based upon something called a certificate issued by a certificate authority (CA). Each CA has a root certificate that can only be created using their private key. You install the certificate issued by the CA CA’s on your web site.

When the CA creates the certificate that is installed on your website, it uses it’s private key and a certificate request containing your public key to create the certificate. The major browser manufacturers put the root certificates of well-known and audited CAs into their software. The browser can then verify that the certificate sent by your web server was issued by the CA. If all of the keys and information matches up correctly, the browser then shows the lock icon.

Certificates are also used for email authentication and encryption and for signing installation media for some programs, but this article will not cover those uses.

Certificate Types

If you look at the underlying architecture for certificates, you will find a myriad of options in how they are used and created. For the purposes of website owners, this can be broken down into a few different categories that differentiate certificates offered by the various certificate vendors:

Certificate Acceptance

Although you can encrypt a web site connection with a self-signed certificate, for the purposes of operating a public web site this is not a realistic alternative. For a public web site, you want to get a certificate from a vendor that has audited identity verification procedures and that is accepted as a Certificate Authority by the major browser vendors:

  • Microsoft (Internet Explorer)
  • Google (Chrome)
  • Mozilla (Firefox)
  • Apple (Safari)
  • Opera (Opera)

There are some free browser organizations that will issue a certificate, but the root certificates are not included in the maintenance streams for the major browser vendors, and are thus not of much use to public website operators. Many of the certificate vendors offer a type of certificate that will meet the needs of most small business owners. There is no reason to get a certificate from an organization that is not accepted as a root certificate authority.

Note that as of October 24, 2016, Mozilla has indicated problems with StartCom that will result in removal of StartCom root certificates from upcoming browser releases. See the Mozilla Security Blog.

Identity Verification

There are essentially three levels of identity verification that the various certificate vendors will use. Although the terminology of “class” is somewhat outdated, it is still commonly used:

  • Class 1 is a certificate with a low level of identity verification. This is sometimes referred to as “domain validation.” The certificate vendor will verify that they are communicating with a person who controls a web site and can place a file in the root directory of the website or respond to email sent to “webmaster”, but will not check government issued identity papers. Certificates with this level of verification are commonly available free of charge from some certificate vendors, and are now available through the free Let’s Encrypt service. For most small web sites, this type of certificate is sufficient.
  • Class 2 is a certificate with a higher level of identity verification. This is sometimes referred to as “organization validation.” The certificate vendor will check drivers licence and other government issued identity documents to verify an individual’s identity, and will require government issued incorporation documents and tax ID information. Certificates with this type of verification typically cost about $250-$500. This type of certificate typically comes with free S/MIME email certificates and code signing certificates.
  • Class 2 Extended Verification or Class 3 is a certificate where there is significantly more identify verification, and will require proof of a physical business address. This type of certificate typically costs more than $500, but comes with a greatly enhanced display in all of the major browsers.

Certificate Uses

Certificate vendors generally issue three types of certificates, with different costs associated with each feature:

  • Email–digitally signing and encrypting email. These are generally issued for Class 1 and Class 2 identity verification levels. Using them requires setting up your email client to do this as discussed in Email Security Part 1: Verifying an Email Sender's Identity Using S/MIME and Email Security Part 2: Digitally Signing Your Email.
  • Website/browser encryption. This is the subject of this article.
  • Code signing. When you install software and Windows or OS X identifies the name of the company that wrote the software in the box prompting for administrator access, that indicates that the software was signed with a code signing certificate. If you do not develop software, this is a feature that you won’t want to pay more to get. It is frequently bundled in with Class 2 or Class 2 EV certificates.

Certificate Domains

Most certificate vendors differentiate their offerings based upon whether or not the certificate will support named or wildcard subdomains. For example www.mooresoftwareservices.com and imap.mooresoftwareservices.com would require seperate individual certificates, a single multi-domain certificate that enumerates the www and imap subdomains, or a wild-card certificate that work for any domain ending in mooresoftwareservices.com. Multi-domain and wildcard certificates are more expensive than single-domain certificates.

Encryption Key Length

The length of the encryption key and the type of encryption supported by the certificate are also a differentiator for certificates. Free certificates typically have shorter key lengths, but typically support at least one of the encryption algorithms in all of the browsers that are actively supported by the browser vendors. At this writing 2048 is the common key length. Some free certificates are issued with a 1024 key length. The key length that you need is really a function of the value of the data. If you have website conversation that would still be valuable five or ten years from now, 2048 and 4096 are the only options, as increases in computing power will make 1024 byte keys easier to crack if an attacker is willing to store the data for a few years to wait for more powerful computers to be manufactured.

Summary of Certificate Types

Table 1 below provides a summary of the groups of certificate features commonly bundled together by the major certificate vendors. In all cases, remember that you are paying for the identity validation, and not the certificate. If you documentation is not in order, you will be charged, but you won’t get a certificate.

Table 1: Types of validation and common features for SSL certificates issued by Certificate Authorities.
Validation   Single Domain Multiple Domain Multiple Domain Wildcard Unified Communications
    Only valid for one domain name, i.e. www.domain.com. If used to secure both website and email as handled in a typical web hosting package, will have to point email to "www.domain.com" instead of "mail.email.com" and set up appropriate aliases in configuration. Would allow same certificate for www.domain.com and mail.domain.com. All domains must be known and listed at time of issuance. Would allow same certificate for www.domain.com and mail.domain.com. Could add a domain after issuance of certificate.

Will not support multiple levels like mail.division.domain.com.

Would allow same certificate for www.domain.com, mail.domain.com, and in addition multiple levels like mail.division.domain.com.
Domain Validation (Old Class 1) Low cost or free. Verification limited to determining if applicant is the webmaster for the domain.

Appropriate for small business and organization web sites that don't do transactions. Gives lock icon shown in Figure 2.

Commonly offered. Inexpensive choice for organizations that don't do transactions. StartSSL offers free one year certificate. Varies by vendor. StartSSL offers up to ten on free certificates. Technically possible, but not commonly offered. Technically possible, but not commonly offered.
Organizational Validation (Old Class 2) Moderate cost, significant documentation required.

Appropriate for small businesses that do transactions, but lower value and volume. Gives lock icon shown in Figure 2.

Commonly issued. Commonly issued. May be a free feature with some certificate authorities. Commonly issued. Usually an additional cost. Not commonly offered.
Extended Validation (more rigorous than Old Class 2) High cost. Extensive documentation required.

Appropriate for businesses that do transactions of high value or high volume. Gives lock and green bar icon shown in Figure 3.

Commonly a free feature of Extended Validation certificate. Commonly a free feature of Extended Validation certificate. Sometimes a free feature of Extended Validation certificate. Usually used by enterprises that are using Microsoft Exchange for email.

Certificate Vendors

There are a number of certificate vendors. To get a complete list, go to your browser’s advanced settings and look for the root certificate authorities. In Firefox, use Options->Advanced->Certificates->View Certificates->Authorities. You want to get a certificate from one of the vendors listed. Generally, your web hosting company will have a relationship with a certificate vendor; this will almost certainly be the easiest option, but it probably is not the least expensive option.

For free Class 1 certificates, Let’s Encrypt is rapidly becoming the easiest choice as it is free and there is a CPanel AutoSSL plugin that makes the installation easy. For most small website operators, this is by far the best choice.

For free Class 1 certificates, StartCom and Comodo offer one year and 90 day certificates respectively (at this writing). Other vendors are beginning to offer free Class 1 certificates through hosting firms, so check with your web hosting firm to see if this is available.

Deciding how to Convert to SSL (HTTPS)

As of November, 2016, the easiest way to convert to SSL depends greatly on software levels and services at your hosting company. This section will hopefully give you information on how to proceed. CPanel 58 introduced AutoSSL, which makes managing certificates easy, but requires a dedicated IP address because CPanel 58 does not allow a different certificate for each email domain. CPanel 60 removed the requirement for a dedicated IP address for using a different certificate for each email domain on a server. Although your hosting service may be at CPanel 58 or 60, they may not have installed the AutoSSL plugin for Let’s Encrypt.

Does your Hosting Firm Support Let’s Encrypt

If your hosting firm supports Let’s Encrypt, your life is easy. You may have to upgrade to a dedicated IP, but first check to see when your hosting firm plans to go to CPanel 60, as this removes this requirment.

Does you Hosting Firm Support AutoSSL

If your hosting firm supports AutoSSL, this is the easiest way to go. In some cases they will use a free certificate service from Comodo or another vendor, but they may charge for certificates, and may charge for adding smtp, mail, imap, and ftp subdomains to a certificate.

Are you on a Super Tight Budget and Technically Confident

If your budget is really tight (you are volunteering for a non-profit) and you are technically confident, you can use CPanel to install your own certificate from StartSSL or another vendor. For instructions on this, proceed to the next section.

Setting up AutoSSL

If you do not need organizational verification–many small businesses and non-profits do not–AutoSSL is a great choice for managing SSL. If you have Web Hosting Manager on a VPS or managed server, see the instructions for installing the Let’s Encrypt! plugin for WHM. Most hosting firms do not install it by default, as they want your certificate money. It is as simple as running a command as root:

/scripts/install_lets_encrypt_autossl_provider

Once AutoSSL installed you can configure it using the Let’s Encrypt Certificate Authority.

Obtaining and Installing A Certificate Using CPanel

If you obtain your certificate through your web hosting firm, they may install it for you, depending upon the type of support plan that you have. If they do not get your certificate through the hosting firm, or they will not install it for you, you will need to do it yourself using CPanel or some other method. The instructions that follow cover the process for obtaining and installing a certificate using CPanel and Web Hosting Manager. If you do not have access to these tools, the installation process requires shell access and commands; the command procedures are outside the scope of this article.

The process falls into four major parts:

  • Get individual and organizational verification from your certificate vendor. This will vary from vendor to vendor.
  • Creating a private key and a certificate request.
  • Sending the certificate request to the vendor and obtaining the certificate from the vendor.
  • Installing the certificate on your website.

Creating a private key and a certificate request

To create a private key and certificate request, log in to CPanel as shown in Figure 9, and select the SSL/TLS Manager as shown in Figure 10. Next, choose the first option to create a private key. It may ask you to move your cursor around to generate random data to be used in the private key.

Once you have created a private key, go to Certificate Signing Requests and Generate a New Certificate Signing Request as shown in Figure 11. Enter the necessary information about your organization using the exact names that are listed on the incorporation and tax documents that you used for identity validation as shown in Figure 12. When you are done, your Certificate Request should show up in CPanel as shown in Figure 13.

Send the Certificate Request file to your certificate vendor via email, or copy it from the window in CPanel and paste it into the certificate request window on the certificate vendor’s web site.

The approach to dealing with each vendor will be different, but for an idea on how things work with StartCom for a free Class 1 certificate, read Securing Your Email Part 2: Digitally Signing Your Email. This article talks about the process for obtaining email certificates from StartCom; the process for web site certificates is very similar.

When you get the certificate from your vendor, go in the CPanel SSL/TLS Manager and select the Certificate section as shown in Figure 15.

Scroll down to the New Certificate section and paste your certificate into the window or upload the certificate file as appropriate for how the certificate was provided to you by your vendor, as shown in Figure 16.

If you have a physical server or a virtual private server (VPS) account, you can use Web Hosting Manager to install the certificate. See the next section for instructions on how to use WHM to install certificates.

Figure 9. Using CPanel
Figure 9.  Using CPanel
Figure 10. Using CPanel SSL/TLS Manager
Figure 10.  Using CPanel SSL/TLS Manager
Figure 11. Using CPanel to generate a private key
Figure 11.  Using CPanel to generate a private key
Figure 12. Using CPanel to generate a certificate request
Figure 12.  Using CPanel to generate a certificate request
Figure 13. Using CPanel to list certificate requests
Figure 13.  Using CPanel to list certificate requests
Figure 14. Passing the certificate request to Start SSL
Figure 14.  Passing the certificate request to Start SSL
Figure 15. Using CPanel to install the certificate part 1
Figure 15.  Using CPanel to install the certificate part 1
Figure 16. Using CPanel to install the certificate part 2
Figure 16.  Using CPanel to install the certificate part 2

Using Web Hosting Manager to Install a Certificate

Installing the certificate in Web Hosting Manager (WHM) is slightly different than the procedure in CPanel. First, go to the SSL/TLS section as shown in Figure 17 and then follow the same steps for creating a private key, creating a certificate request as given for CPanel, but make sure that you select the correct web host. When you get the certificate back from the vendor, install it on the correct host as shown in Figure 18. If you have only one domain on the server, you can assign the certificate for use by the email and FTP servers. WHM does not currently support using seperate certificates for email domains in the same way that it does for web hosting.

Finally, you will need to configure Joomla to SSL as described in the next section.

Figure 17. Using Web Hosting Manager to install certificate: Part 1
Figure 17.  Using Web Hosting Manager to install certificate: Part 1
Figure 18. Using Web Hosting Manager to install certificate: Part 2
Figure 18.  Using Web Hosting Manager to install certificate: Part 2

Configuring Joomla for SSL

Configuring Joomla for SSL is the easy part in this process. In the Admin Console, go to Global Configuration->Server and change the “Force SSL” option from the value of “none” shown in Figure 19 to “all”. Next, if you have Akeeba Admin Tools, you may consider forcing all external links to HTTPS as shown in Figure 20. This can break some things, but is an important safeguard against man-in-the-middle attacks if you retrieve fonts, JavaScript or other items from other sites. If you do not use this option, make sure to inspect all links for HTTPS use wherever possible.

If you use Akeeba Admin Tools to generate your .htaccess file, go to the bottom of the generator page and enable HTTP Strict Transport Security (HSTS) in headers.

Figure 19. Configuring Joomla to Force HTTP to HTTPS. Change the “none” value to “all”.
Figure 19.  Configuring Joomla to Force HTTP to HTTPS.  Change the “none” value to “all”
Figure 20. Configuring Akeeba Web Master Tools to convert SSL. Change the “No” value to “Yes”.
Figure 20.  Configuring Akeeba Web Master Tools to convert SSL.  Change the “No” value to “Yes”
Figure 21. Configuring Akeeba Web Master Tools to Turn on HTTP Strict Transport Security (HSTS)
Figure 21.  Configuring Akeeba Web Master Tools to Turn on HTTP Strict Transport Security (HSTS)

Set up .htaccess Without Akeeba .htaccess Generator

If you use Akeeba Admin tools to generate your .htaccess file, it will take the setting from the Joomla Configuration and add the necessary code to your .htaccess file. If you do not use Akeeba Admin Tools to generate your .htaccess file, you will need to manually set up your .htaaccess file to redirect all HTTP traffic to HTTPS. Before making any changes to .htaccess make sure that you have shell access or can otherwise manually edit the file, as a mistake can leave you unable to get to the site via the web admin interface.

RewriteCond %{HTTP_HOST} ^yourdomain.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.yourdomain.com$ [NC]
RewriteRule ^(.*)$ https://www.yourdomain.com/$1 [R=301,L]

Let Google Know

The final step in the process is to register the HTTPS version of your web site with Google Webmaster tools and with Google Analytics.

Check the Encryption Protocols on Your Web Site

Once you have everything set up and working, you should check to see that your server is configured to accept only encryption protocols that cannot be cracked and other encryption configuration errors. The Qualsys SSL Labs web site provides an easy to use web service that emulates a number of browsers and tests your SSL certificates and configuration.

Make sure to check the browser support list; if you are dependent upon traffic from a very old, compromised browser, you will have to enable some very old, compromised encryption protocols with the associated risks.

If you want to read more on the subject SSL and TLS Deployment Best Practices is a good article on how to set up SSL in the most secure way.

Setting up a Test Environment

To verify that all of your add-ins work with SSL, you can generate a self-signed certificate on your test server. If you want to practice the key generation and certificate request process, you can become your own private certificate authority by using an application like XCA or another certificate management application.

Lenovo Superfish

At this writing in the winter of 2015, there has been much discussion of “Superfish” software that Lenovo installed on a number of laptop computers that it shipped in the fall of 2014. The Superfish software was used to insert ads into browser sessions. In a very abbreviated description, Superfish intercepted certificates, decrypted the stream and pass on its own valid certificate to the end browser so that the end user was largely unaware that a man-in-the-middle attack was occuring in an encrypted session. I have not fully researched an implemented the issue, but Certificate Pinning appears to be the current approach to protect against Superfish-type malware. Enabling HSTS may provide some protection against this type of attack, but I’m not sure at this point.

Summary

There are a number of security and search engine optimization (SEO) reasons that small business and organization web site owners should configure SSL encryption on their web sites. Free or low-cost certificates are increasingly available, so this is no longer the financial burden that it once was.

The slides for my March 9, 2015 presentation to the Dallas/Ft. Worth Joomla user group are here.

This web site uses cookies to provide user authentication and improve your user experience through the use of Google Analytics and Matomo Analytics. It also uses contact information for email and phone communcation. For details, see the Privacy Policy.