Choosing the best HTTPS certificate (HTTPS Everywhere – Part 2)

When the users browser requests an HTTPS connection to a webpage on your server, the server needs to send back its TLS or HTTPS certificate.

This initial exchange to setup a secure connection is called a TLS / SSL handshake.

The browser will do the necessary checks to see if the certificate is still valid, is for the correct site (eg. https://www.myexamplewebsite.com) and more.

To acquire a certificate, you’ll need to buy one from a certificate authority. A certificate authority is a company which is trusted by the major browsers to issue valid certificates. Well known names include Comodo, VeriSign and more.

There are a few things you need to know about the different certificate types that exist before you can buy one.

Standard HTTPS certificate

A standard certificate can be used for a single website domain. Eg. if all your content is hosted on www.mywebsite.com, you could buy a standard certificate which is valid for www.mywebsite.com. Note this doesn’t include any subdomains which you may also use.

For example cdn.mywebsite.com is not included. Browsers will issue warnings to the user if you try to use a certificate which is not valid. You could by a second certificate for the subdomain cdn.mywebsite.com to solve this problem.

Wildcard HTTPS certificate

A wildcard certificate is still only valid for one top domain (eg. mywebsite.com), but it also supports all subdomains (*.mywebsite.com); hence the name wildcard certificate.

This kind of certificate is usually a little bit more expensive, then a standard certificate. Depending on the price and on the number of subdomains you’re going to use you’ll need to decide between a standard and wildcard certificate.

Other types of HTTPS certificates exists (eg. Multidomain), but are usually pretty expensive; so we’ll not cover them here.

Public and private key length

Certificates work with public and private keys to encrypt the communications running over https. Anything encrypted with the public key can only be decrypted by someone who has the private key. Anything encrypted with the private key can only be decrypted by the public key.

When a browser and a web server communicate with eachother, the private key needs to remain in a secure location on the web server. The public key is intended to be distributed to the browser, so it is able to decrypt the information which was encrypted with the private key.

To counter brute-force attacks that are trying to acquire the private key in use, the key needs to be big enough. In the past 1024 bit keys were generally created by the certificate authorities. Nowadays you should use 2048 bit keys, because 1024 bit keys have become to weak. (we’ll guide you through the technical details later)

Extended Validation HTTPS certificates and the green bar in the browsers

Earlier we said that a https certificate for a website proves that users communicate with the intended website and not a fake website run by malicious people.

Of course the Certificate Authority plays a vital role in this: when you order a certificate they should verify you’re the owner of the domain name.

With a normal certificate the validation is quicker and less extensive then when you order an EV (Extended Validation) certificate. An EV https certificate is more expensive due to the extended manual verification of the site owner.

Browsers do place a lot more trust in an EV certificate. They will display the name of the company inside a green bar in the browsers address bar. For example:

An EV certificate could be interesting for an ecommerce site because it gives your user a greater trust in your site which could lead to more sales.

There are some restrictions with EV certificates though: only companies can order an EV certificates, individuals cannot. EV certificates are always for one domain only; there are no wildcard EV certificates at this moment.

In Part 3 we explain how to buy a HTTPS Certificate.