SSL Certificates from start to finish


We have been receiving more than the average number of support tickets relating to SSL (Secure Sockets Layer) certificates of late, so we have decided to put together this post which will hopefully answer any questions that you might have about SSL certificates: how to get them, how they work etc., as well as some questions you didn't know you had yet.

The basics It's always a good idea with these sorts of posts to start at the very bottom and work our way up, so let's start with what an SSL certificate is, what it is meant to do, and have a look at the various types of certificates that are on offer: You will see these things all over the web now, and their usage is becoming increasing common (which probably explains our recent spike in support calls about them) as general Internet users become more aware of their online security.

The purpose of an SSL certificate is allow for Internet traffic to pass through a secured channel (and you'll see this with web addresses prefixed with https:// rather than the more standard http:// - the additional 's' standing for secure), as well as to confirm the identity of the owner of the website. When looking at a website, apart from the presence of the https:// prefix, you will often see somewhere - either in the address bar at the top or the status bar at the bottom of the screen - a padlock, which when clicked, will display the full SSL certificate. That certificate shows the holder's details and the website address to which it belongs. An example of both of these concepts is shown below:

https:// prefix and padlock

A certificate for the website we are looking at 

As you can see from the above images, we have the https:// prefix shown in our browser's address bar as well as the padlock icon. We have clicked that to show the details of the certificate which shows that the certificate is issued for google.com.au which is indeed the site that we are looking at, and the circled items show that the certificate is currently valid (it's 1st October 2012 as this post is written).

Types of certificate As with everything that really ought to be easy, it is in fact considerably more difficult than it would first appear to get an SSL certificate because there are in fact a vast number of different types of certificate available, from any number of different providers.

We couldn't possibly hope to show every type of certificate from every provider, and wouldn't even try, but we can show the general "types" of certificate that pretty much all providers will be able to supply. Of course, some will be able to provide more and/or different certificates, but these are the base. A basic SSL certificate will link to one SUB-DOMAIN, nothing fancy, just a simple SSL certificate which confirms the identity of the website that you are looking at matches the address that you have navigated to. There are a couple of points to note here, as follows:

  1. Use of the word sub-domain ... it is very important. You are probably aware of what a domain name is (example.com for instance), and that each prefix of that domain is a sub-domain (for example, mail.example.com or ftp.example.com). What many people don't realise however is that www is also a sub-domain (www.example.com). To compound this somewhat, many websites link www.example.com and example.com to the same set of pages, these are in fact two separate sub-domains and would therefore require two different basic SSL certificates. Be aware of that, it trips a number of people up. It is in fact good practise to only use a single version of your domain name (either with or without the www, whichever you prefer) and employ some kind of code-based redirection to ensure users always use the same URL. This helps with SEO too, but that's a matter for a different post.
  2. A basic SSL certificate merely confirms that the address that you think you are looking at is in fact the address that you are looking at, and that there is not another server somewhere pretending to be example.com

Almost identical to the basic certificate above except that it avoids the problem pointed out in pitfall number one, whereby multiple sub-domains are used. A wild card SSL certificate allows you to confirm an entire domain name so anything.example.com would be covered as well as www, ftp, mail and any other sub-domain that you choose to create. Pitfall two above still applies however, in that there is no actual identity check of the website owner, only the address itself. With BusinessID (and the name may change between providers), we are able to eliminate pitfall number two above.

When requesting this type of certificate, one must provide full contact details as well as other information for the identity of the certificate holder. The certificate provider will then make the necessary enquiries using whatever means they can to establish definitively that the entity requesting the certificate is who they purport to be. Business ID certificates look slightly different when viewed because they actually show the name of the entity (usually a company) which holds the certificate as well as just the domain name to which the certificate applies. This is the top-of-the-line solution, and the way to tell it is that the address bar of your web browser will go green (usually), and display the full name of the certificate registrant in the address bar, as shown below:

Extended Validation (EV) example

We can see in the example above that our address bar is shown in green, and the certificate registrant's name - Microsoft in our example - is shown circled.

Obtaining an SSL certificate Generally speaking, obtaining an SSL certificate is as easy as placing an order for it as most people will opt for either a Basic or a Basic with wild card certificate - mostly due to the cost implications of the others. In this case, you would place an order through the billing system and the process will largely be taken care of for you. As usual though, there is a gotcha in the process which should be explained so that it doesn't become a blocking issue: When you order your SSL certificate, you would generally do so through a reseller company (we at Expeed are resellers for example).

That reseller is allowed to place the order on behalf of the registrant, but the registrant must be the one who "fulfils" the application given that they will be the ultimate holder. Therefore, the registrant (you) will receive an e-mail from the SSL certificate issuer asking you to confirm that an SSL certificate was requested in your name, or for your website, so that it can be fulfilled.

This is done to prevent an unauthorised third party requesting an SSL certificate on behalf of a website that they were wishing to target and making it appear legitimate. For example, if you were to set up shop using your domain name of MyWidgets.com but a nefarious third party requested an SSL certificate for that domain name, that third party could easily pretend to be the legitimate owner of the domain. The fulfilment requirement ensures that only the legitimate owner of the domain is the one who requests the SSL certificate. As a further complication to this process, there are only a few e-mail addresses that are considered "valid" from which to request that fulfilment takes place, as follows:

  • admin@yourdomainname.com.au
  • administrator@yourdomainname.com.au
  • hostmaster@yourdomainname.com.au
  • root@yourdomainname.com.au
  • webmaster@yourdomainname.com.au
  • postmaster@yourdomainname.com.au

If you are going to request an SSL certificate, make sure you have one of those e-mail addresses set up before you start. It will just make the process so much easier.

The tricky questions you will get asked During the order process, besides the standard contact name and address details, you will be asked for a few data items that are specific to SSL certificates. At first glance, they can appear to be slightly non-sensical, so they are worthy of special mention below: SSL Website URL: This is the full name of the website that you would like to secure. Remember that in the case of a non-wild card certificate, this may want to include the www. Refer to pitfall one (above) in the Basic SSL section.

Approver e-mail address: This must be one of the "valid" e-mail addresses shown above

Organisation name: The name of the company that is the registrant. If you are not getting the certificate on behalf of a company, then this would be your name

Organisation unit: This is the department name within a company. If no such thing exists, enter IT Department or something similar. It is of little importance but must be supplied.

City: The city in which you or your company are located

State: The state in which you or your company are located With those questions answered, an SSL certificate and be requested and the rest of the process should be pretty transparent to you.

Activating the certificate for your website(s) If you have shared hosting then you have no need to worry about adding the certificate to your site because it will be done for you. If, on the other hand, you have a VPS (Virtual Private Server) then you are going to need to do some work in order to create the request item, accept the response certificate and update the website bindings to use the certificate. From within Internet Information Services (IIS), you will need the Server Certificate's applet (accessed by clicking the server name node from the left menu) as shown below:

Server certificates applet in IIS

From here, click "Create certificate request" from the right hand bar to begin the process. You will need to complete the fields as per the "tricky questions" section above; bear in mind here that the website url will be asked for by the name of "Common Name". If you are requesting a wild card certificate then your common name will need to begin with the wild card character which is an asterisk (*), therefore, your common name will be *.domainname.com.

Other settings will be advised to you by your certificate provider but generally the default cryptographic provider (Microsoft RSA SChannel Cryptographic Provider) is the one you need. Be aware though that you will usually need a bit length of at least 2048 - in fact, 2048 is generally the requirement. This process will create a text file which contains the request string. When your provider asks you for that request string, they will need the entire contents of the file including the -- BEGIN -- and -- END -- lines.

What you will receive back from your certificate provider is the textual content of a certificate. Again, as above it will be prefixed and suffixed with -- BEGIN -- and -- END -- lines, and once again, these lines also make up the certificate reply. Paste the entire text that you receive into a new text file on your server, but name it with a file extension of .cer (for certificate).

Bear in mind also that you may renew the certificate every year or two, so try to choose a name that is easily distinguishable. So, www.mydomain.com.2012.cer is a reasonable format. It is important that the text be pasted unedited, so you will need to use a simple word processor such as Notepad. It would not be advisable to paste into Microsoft Word or WordPad as they will add their own hidden characters that will render the certificate useless. Also, make sure that the file name has an extension of .CER otherwise it will not be found in the next step.

Be aware than if you are hiding the file extensions for known file types, your new document will end up with a .txt.cer extension and that will fail! In order to import the certificate, you will once more need to be in IIS's Server Certificates apples (shown above), but this time, from the right hand side choose "Complete Certificate Request".

You will be asked to locate the .CER file created above, and to select a friendly name. It is of utmost importance that the Friendly name contain the year, otherwise, when you come to bind the certificates you may find many certificates - all for different years - with the same name in the list, and there is no order with which to make an educated guess. This is a frustration you learn to deal with in advance after the very first time of encountering it! All being well, your certificate will be incorporated and can now be bound to a website.

Now that we have made our request, received our response, and incorporated our certificate, we need to attach (or bind) the certificate to the website that we would like to use it for. Back into IIS, and we select the website that we are interested in from the list on the left (remember to expand the server name and then the sites node to see all of the websites and BE SURE to select the correct website). On the right hand side menu, we click the item called "Bindings ..." to display the dialogue box below (yours may have different items listed but that doesn't matter)

IIS Bindings dialogue box

Click the "Add" button from the right hand side of the dialogue box. Change the "Type" field to https and you will notice that a new dropdown field entitled "SSL Certificate" is shown. From here, you can select the certificate - based on the very important friendly name from before - and click OK. The processing can take a little while, but then you are done. Remember to test your website with the https:// prefix and ensure that there are no error messages, and that clicking the padlock shows the correct information.

Renewing your certificate Like domain names, SSL certificates are only valid for a set period of time - usually one or two years - after which they need to be renewed. You will get a number of automated e-mails about renewal so be sure that your registered e-mail address is kept up-to-date. Usually, you will receive e-mails 90 days before expiry, 60 days before, 30 days and five days before, and then finally on the date of expiry. Renewing is done by purchasing  a new certificate and starting over. A note for those of you with VPS installations: generally the SSL certificate renewal system from within IIS is unsuported with providers now. Therefore, treat every renewal as a brand new certificate and follow the steps outlined above. This is where the friendly name as mentioned becomes very important.

Summary An SSL on your website shows that you take your users' security seriously, and do as much as you can to provide them with a safe browsing session on your website and that you have taken at least the steps necessary to preven their confidential data from being leaked out to the world. SSLs are not the be-all and end-all of security, they are a small fraction of the entire security requirements, but they are reasonably inexpensive, easy to install and are an important peice in protecting you and your website visitors. Users are increasing savvy about interactions over the Internet and are increasing weary of who they give their data to, and what those companies do with that data. Users now activiely look for the padlock or the green address bar when filling in forms whereas they didn't a few years ago. If you have neither then you will be losing registrations and customers, there is absolutely no doubt about that.    

Post Tags: Account Management , Configuration , Domain , Hosting , How To , Information , Instruction , Learning , Security , Settings , SSL , Teaching , Virtual Private Server , VPS