Summary of the procedure for HTTPS Conversion

1. Generate the private key file & CSR for HTTPS certificate
2. Choose a company to buy your ssl certificate from
3. Once you have the company, purchase the desired cert (normal or ev), and in the purchase process, Submit the CSR you generated & get the SSL certificate after ward.
4. install the SSL certificate into the webserver.
5. Redirect traffic from http to https.
6. Update Google Analytics property to https.
7. Add a new site with https on Google Webmaster Tools.
8. Remove the http Google Webmaster Tools account link from Google Analytics.
9. Add https Google Webmaster Tools account link on Google Analytics.

Generate the private key file & CSR

(a csr is the ‘certificate signing request’ which is the starting point of conversion to https. A csr is a bunch of text in a text file).

1. If you’re using a VPS with Linux, then you can use ‘openssl’ to create private and CSR file. For details on the open ssl procedure, visit a new page on oig site: (this will contain a command line input and output for the process). Mention here that you have to be logged in as root

I. Login as root, using ssh to the production server
II. To generate the private & csr file
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr

This creates a two files. The file myserver.key contains a private key; do not disclose this file to anyone. Carefully protect the private key.

In particular, be sure to backup the private key, as there is no means to recover it should it be lost. The private key is used as input in the command to generate a Certificate Signing Request (CSR).

You will now be asked to enter details to be entered into your CSR.
What you are about to enter is what is called a Distinguished Name or a DN.
For some fields there will be a default value, If you enter ‘.’, the field will be left blank.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Please enter the following ‘extra’ attributes to be sent with your certificate request

A challenge password []:
An optional company name []:

Use the name of the web-server as Common Name (CN). If the domain name (Common Name) is append the domain to the hostname (use the fully qualified domain name).

The fields email address, optional company name and challenge password can be left blank for a webserver certificate.

Your CSR will now have been created. Open the server.csr in a text editor and copy and paste the contents into the online enrollment form when requested.

2. If you’re using a shared hosted account:

I. First you need to buy a dedicated IP for your shared hosted account.
II. Next you need to locate the ‘SSL’ settings in your hosting dashboard (might be cpanel but can change based on hosting company). On the SSL settings, you need to provide the following details: the FQDN on which you want to use SSL (be cautions about www and without www), and location of the company (state, city, country)

Choose a company to buy your ssl certificate from.

What is Extended Validation SSL Certificates

An Extended Validation SSL Certificate is a “top of the line” SSL certificate. Obtaining one requires that a company go through a heavy vetting process, and all details of the company must be verified as authentic and legitimate before the certificate is issued. While this certificate may seem similar to an Organization Validation SSL certificate, the key difference is the level of vetting and verification that is performed on the owner of the domain and the company that is applying for the certificate. Only a company that passes a thorough investigation may use the Extended Validation SSL certificate, which provides users of the company’s website with security and reliability.

Validation modes

The general purpose of a (public key) certificate is to bind an identity to a public key (therefore binding the identity to the server using the corresponding private key in the SSL/TLS handhsake).

Lucas Kauffman has already written an answer detailing the difference between domain-validated certs, organization-validated certs and extended-validation certs. The real question you need to ask yourself is what you are trying to prove to the user.

The difference between these types of certificates is how that identity itself is defined.

The domain-validated certificates guarantee you that the certificate was issued to the owner of that domain. No more, but no less (I’m assuming the validation procedure was correct here). In many cases, this is sufficient. It all depends on whether the website you are promoting needs to be linked to an institution that is already well known off-line. Certificates that are validated against an organization (OV and EV certs) are mainly useful when you need to tie the domain to a physical organization too.

For example, it’s useful for a institution that was initially known via its building (e.g. Bank of America) to be able to say that a certificate for is indeed for the place where you’ve given your physical money. In this case, it makes sense to use an OV or EV certificate. This can also be useful is there is ambiguity regarding which institution is behind the domain name (e.g. and, which is even more important is the similar domain name is owned by a rival/attacker using the name similarity for bad purposes.

In contrast, is what defines Google to the public; Google has no need to prove that belongs to the real Google. As a result, it’s using a domain-validated certificate (same for

Again, this is really useful if the user knows how to check this. Browsers don’t really help here. Firefox just says “which is run by (unknown)” if you want more details about the cert at, without really saying what is meant by this.

Extended-validation certificates are an attempt to improve this, by making the organization-validation procedure more strict, and by making the result more visible: green bar and more visible organization.

Unfortunately, this is sometimes used in a way that increases confusion, I think. Here is an example that you can check by yourself: one of the large UK banks (NatWest) uses the for its on-line banking services. It’s far from obvious that the domain name belongs to NatWest (who also own the more logical name, by the way). Worse, the extended validation (if you check the name next to the green bar) is done against “Royal Bank of Scotland Group plc”.

For those who follow financial news, it makes sense because both RBS and NatWest belong to the same group, but technically, RBS and NatWest are competitors (and both have branches on the high street in the UK — although that’s going to change). If your user doesn’t have that extra knowledge about which groups trade under which name, the fact that a certificate is issued to the name of a potential competitor should ring alarm bells. If, as a user, you saw a certificate on issued to Microsoft or Yahoo, however green the bar is, you should not treat this as Google’s site.

One point to bear in mind with EV certificates is that their configuration is hard-coded into the browsers. This is a compile-type setting, which cannot be configured later on (unlike normal trusted certificate stores, where you could add your own institutional CA cert, for example). From a more cynical point of view, some could consider this as a convenient way for the main players to keep a strong position in the market.


Some CAs also offer various “seals” that you can put on your website, usually with different colours depending on the type of certificate you purchased. They seem to be intended as an extra step to prevent less-reputable CAs issuing a valid certificate to the wrong party.

As far as I’m aware, these are completely useless from a security point of view. Indeed, when you click on it to have your certificate verified (for example, if you click on GoDaddy’s “verified an secure” logo, you end up on this page), nothing tells you that the certificate you see is the same as the one that’s sent to the service behind Indeed, if there was a MITM attacker between you and, with another valid certificate for issued by a sloppy CA, that MITM attacker wouldn’t be between and Unless the user really looks at the certificate in detail, the seal wouldn’t help very much (bearing in mind that the attacker could simply remove the seal link or point it to the one from the other CA).


Some certificates also come with some sort of insurance. You would get some sort of compensation should something go wrong during a transaction up to a limited amount. It’s not clear to me what the conditions to claim such insurance would be.

There is a reason to pay more for a certificate : – $10M (for example) protection insurance if the certificate is compromised.

Godaddy Price:
Protect One Website $55.99 /year
Protect Multiple Websites $179.99 /year
Protect All Subdomains $269.99 /year
SiteLock Website Security $17.88/yr
Deluxe SSL OV $99.99/yr
Standard SSL $69.99/yr
Premium SSL EV $149.99/yr
Verisign Price :
Secure Site Pro with EV $1,499/yr
Secure Site with EV $995/yr
Secure Site Pro $995/yr
SSL Wildcard $1,999/yr
Secure Site $399/yr
Comodo Price:
Comodo SSL UCC $235/yr
Comodo EV SSL $359/yr
Comodo Wildcard SSL $334.95/yr
Comodo SSL $64.95
GlobalSign Price:
DomainSSL $249/yr
OrganizationSSL $349/yr
ExtendedSSL $899/yr
Wildcard SSL $899/yr
DigiCert Price:
SSL Plus $175/yr
Extended Validation $295/yr
Unified Communications $299/yr
EV Multi-Domain $489/yr
Wildcard Plus $595/yr

(any reason to not buy godaddy?)

Some ssl review sites?

Also – geotrust offers a seal which statistically may enhance user conversion

Once you have the company, purchase the desired cert (normal or ev), and in the purchase process, Submit the CSR you generated & get the SSL certificate after ward (may take 20 min), EV certs take days because of research & verification. Note that the certificate is a text file.

Now you have to install the SSL certificate into the webserver

1. If you’re using a VPS with Linux, then you need to modify apache setting to use the https certificate. View the procedure / steps here:

2. If you’re using a shared hosted account, you need to use their provided tools such as cpanel (which you used to create the private key file & the CSR) to install the https certificate.

Redirect traffic from http to https using .htaccess file

Typically this is done with an entry like this: (paste line from .htacecss)

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Change from http to https on the Google Analytics property for the domain

Add a new site with https on Google Webmaster Tools (your old site with http won’t be relevant but keep it for reference for older data). Make sure to add the new path (with https) to the sitemap configuration.

Remove the previously linked Webmaster site (http) with Google Analytics

Establish a link between newly created Webmaster site (https) with Google Analytics Account.

If you have bing webmaster tools active, remove the existing sitemap path, and add the new sitemap using https in the path.