SSL Implementation: PAID v/s FREE

Learn about SSL

In my last article I explained in and out about “What is SSL/Encryption and why we need that”. If you haven’t read about that yet then I request you to first go through that.

In this article we are going to learn about the implementation part of SSL.

Table of Contents

SSL Implementation Approaches

1. PAID
Prerequisites
Implementation Process overview
Where Do I Buy an SSL Certificate?
Who is trusted Certificate Authority (CA)?
What is Certificate Chain?
What is a Root SSL Certificate?
What is an intermediate Certificate?
How to order an SSL Certificate?
How to Install certificate once issued

2. FREE
When do we go with FREE Approach?
When can we use self signed certificates?
Generate a Self-Signed Certificate
Verify on browser

SSL Implementation Approaches

There are two types of strategis to implement SSL.

1. PAID
2. FREE

PAID

If you are running a public facing website then you must buy SSL certificate and SSL certs are now a requirement for all websites. The browsers led by Google and Mozilla have mandated all sites be served with encryption via HTTPS.

Do your homework before buying

You must understand your requirements before you purchase SSL Certificate. There are several types of Certificates like, Single Domain, Wildcard SSL, Multi-Domain etc. If you have only one domain to secure, you should go with single domain certificate. They are cheap as well. If you have main domain and sub-domains to secure then buy wildcard. If you have multiple domains to protect, go with multi-domain cert.

Prerequisites

1. Host with a dedicated IP address

Implementation Process

1. Buy a certificate
2. Activate the certificate
3. Install the certificate
4. Update your site to use HTTPS

Where Do I Buy an SSL Certificate?

SSL Certificates need to be issued from a trusted Certificate Authority (CA). Browsers, operating systems, and mobile devices maintain lists of trusted CA root certificates.

The Root Certificate must be present on the end user’s machine in order for the Certificate to be trusted. If it is not trusted the browser will present untrusted error messages to the end user.

Specially for e-com websites, such error messages result in immediate lack of confidence in the website and organizations risk losing confidence and business from consumers.

Note that end user SSL certificate is only one part of a certificate chain.

Lets understand this whole eco-system one by one.

Who is trusted Certificate Authority (CA)?

A trusted certificate authority is an entity that’s entitled to verify someone is who they say they are. In order for this model to work, all participants must agree on a set of trusted CAs. All operating systems and most web browsers ship with a set of trusted CAs.

For example on Windows OS you can find it here:

On Chrome Browser you can find it here:

What is Certificate Chain?

SSL certificates operate on a structure called the certificate chain — a network of certificates starting back at the issuing company of the certificate, also known as a certificate authority (CA). These certificates consist of root, intermediate, and leaf (server) certificates.

Now the question arises in my mind: how does my browser know to trust a website’s SSL certificate? We’ve covered that any certificate descendant of a trusted root is, by extension, trusted.

When you arrive at a website, your browser takes a look at its SSL certificate and performs a quick process to verify the certificate’s authenticity. It checks its validity dates, ensures the certificate hasn’t been revoked and it authenticates the certificate’s digital signature.

What your browser is doing to authenticate the certificate is following the certificate chain. Now, when a browser sees the SSL certificate, it sees that the certificate was issued by one of the trusted roots in its root store (or more accurately, signed with the root’s private key). Since it trusts the root, it trusts any certificate the root signs.

What is a Root SSL Certificate?

A Root SSL certificate is a certificate issued by a trusted certificate authority (CA).

The SSL ecosystem is based on a model of a trust relationship, also called the “chain of trust”. When a device validates a certificate which you present to them with your website, it compares the certificate issuer with the list of trusted CAs. Lacking a CA’s root certificate, no browser would know whether to accept an SSL certificate issued by that CA. The top of the chain, the root certificate, must be issued by a trusted Certificate Authority.

What is intermediate certificate?

Intermediate certificates are designed to alleviate risk by creating a separator between the root and SSL certificates. This is because issuing a certificate straight from the root would be too dangerous if it were to become compromised, as the root certificate has the most authority and needs to be protected.

All CA’s make use of intermediate certificates that have been signed by the root certificate, and those in turn are used to validate end users’ certificates.

Sometimes your CA which issues an SSL certificate will also send an intermediate certificate that you’ll need to install, too. That’s so that browsers will be able to complete the certificate chain and link the SSL certificate on your server back to one of its roots.

Here’s a practical example, Google and the other browsers recently distrusted Symantec CA brand SSL certificates.

How did the achieve this?
It was very simple. They just removed all of Symantec CA’s roots from their trust stores. Now any SSL certificate that is supposed to chain back to those roots fails and is distrusted.

So far we have understood the whole certificate chain process.

Now lets go back to our original question of where do I actually buy it?

There are many trusted SSL certificate providers in the market because browser and operating system vendors trust them as a legitimate Certificate Authority and can be relied on to issue trustworthy SSL Certificates.
for example -
1. Comodo SSL
2. DigiCert
3. Entrust Datacard
4. GlobalSign

and so on ..

How To Order An SSL Certificate

• Prepare by getting your server set up and getting your WHOIS record updated (it needs to show the correct company name and address), etc.
• Generate the CSR on the server

You need to generate a CSR and private key on the server that the certificate will be used on.

[root@myserver ~]# openssl req -new -newkey rsa:2048 -nodes -out myserver_example_com.csr -keyout myserver_example_com.key
Generating a 2048 bit RSA private key
...................................................................+++
..............................................................................+++
writing new private key to 'myserver_example_com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:us
State or Province Name (full name) []:california
Locality Name (eg, city) [Default City]:milpitas
Organization Name (eg, company) [Default Company Ltd]:Example, Inc.
Organizational Unit Name (eg, section) []:NOC
Common Name (eg, your name or your server's hostname) []:myserver.example.com
Email Address []:root@myserver.example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[root@myserver ~]# ls -l myserver_example_com.csr
-rw-r--r--. 1 root root 1086 Sep 21 13:11 myserver_example_com.csr
[root@myserver ~]# ls -l myserver_example_com.key
-rw-r--r--. 1 root root 1708 Sep 21 13:11 myserver_example_com.key

Decoding a CSR
Once you have generated a CSR with a key pair, it is challenging to see what information it contains as it will not be in a human-readable format.

[root@myserver ~]# openssl req -in myserver_example_com.csr -noout -
text
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=us, ST=california, L=milpitas, O=Example, Inc., OU=NOC, CN=myserver.example.com/emailAddress=root@myserver.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ec:a1:26:62:fd:6d:44:66:89:91:bf:56:ce:c1:
                    5b:b6:fe:72:b0:bd:f4:27:ea:ca:2e:38:24:49:26:
                    b3:81:64:05:43:f8:81:9f:fb:6c:be:4c:cc:03:ad:
                    4c:45:58:d2:f5:b0:bc:94:50:6c:00:c5:27:2a:25:
                    4a:a3:18:40:e2:6e:cd:67:09:05:db:7a:72:0f:43:
                    09:76:8c:cd:21:c7:91:f5:82:e6:4b:03:28:3f:0f:
                    7d:b1:6b:7c:60:f7:03:dd:ba:2c:e2:d4:fd:0d:6b:
                    e6:ba:9d:30:87:a3:a6:c0:8b:05:d5:38:76:99:40:
                    76:20:fd:57:f2:12:b3:11:e6:3c:69:30:b2:04:d0:
                    c9:d3:b3:1d:b2:48:60:93:95:35:32:5a:34:93:9c:
                    f6:fd:7f:59:5a:c4:2d:ff:e7:cd:c1:95:77:89:08:
                    3f:57:aa:68:6c:27:61:82:96:96:24:2d:2f:fe:ff:
                    cb:84:99:cc:04:2c:00:12:2b:4c:e4:b9:6f:cd:03:
                    69:bf:4d:51:94:8b:15:b0:0b:e9:57:87:38:86:16:
                    58:89:98:28:81:e1:4c:aa:28:91:08:48:c1:8c:0b:
                    f0:c0:e7:c9:5f:cf:ec:ce:46:3d:4c:2c:13:76:ad:
                    2f:ee:00:5d:a9:93:5b:04:ba:5c:96:f0:c7:42:92:
                    33:c9
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         75:0b:a9:3e:91:c2:3d:e8:1d:6a:45:c9:4d:85:2e:db:82:87:
         b6:a5:b9:f3:46:97:d6:b0:98:f6:d4:5c:5d:ef:b9:c8:42:4f:
         39:d8:b8:4d:88:5e:07:9c:0e:60:34:41:bb:02:c1:ee:c6:74:
         d9:71:1d:86:f7:79:ad:9b:ab:7a:c7:59:27:9b:5d:37:53:52:
         f6:1c:a6:20:75:ea:98:a4:03:71:b2:81:dd:7c:4e:f8:53:d3:
         ef:9e:df:ce:cd:f1:55:1d:4e:de:4c:42:73:3c:dc:b4:ee:d2:
         50:f4:b1:b1:b4:f0:77:f0:c2:57:d8:70:f6:2b:15:f0:1d:60:
         c3:3c:1e:4c:46:01:cb:8b:7e:3b:c6:e2:8a:0b:ca:e0:a0:32:
         2f:fd:55:f9:68:60:76:1e:8d:ea:96:7c:11:a0:e6:59:24:e4:
         e4:6b:b2:f4:24:1e:ca:01:d9:33:d6:cf:37:d1:ef:c9:5e:ef:
         b6:58:97:4d:93:df:e5:ac:d9:77:0b:08:66:ea:b2:8d:29:aa:
         f8:72:52:08:68:62:bd:e3:5c:d2:83:5c:ba:58:0c:d5:48:91:
         3d:a0:67:52:a9:da:71:0a:30:ea:8b:84:c6:76:d8:eb:ce:3e:
         d8:39:e1:ef:fe:f0:bf:a2:df:35:0c:34:a6:23:44:7c:c1:7b:
         0d:7e:89:56

• Submit the CSR and other info to the Certificate Authority who will verify your legal identity and whether you own and control the domain submitted in the application.
  The CA runs a check on your organization and validates if the organization is registered at the location provided in the CSR and whether the domain exists. When verified, your organization receive a copy of your SSL certificate including business details as well as the public key. You can now install the certificate on your server.
  When a CA issues the certificate, it binds to a certificate authority’s “trusted root” certificate. As we have learn above Root certificates are embedded into each browser and connected to individually issued certificates to establish an HTTPS connection.
• Receive and install the issued certificate
  First verify Whether theCertificate and Private Key Match

To verify, you need to print out md5 checksums and compare them. Execute the following command:

[root@myserver ~]# openssl x509 -noout -modulus -in myserver_example_com.crt | openssl md5
(stdin)= 42101340b71a9c4f71db14b135cffa6f
[root@myserver ~]# openssl rsa -noout -modulus -in myserver_example_com.key | openssl md5
(stdin)= 42101340b71a9c4f71db14b135cffa6f

To install the issued certificates we will take an example of Apache webserver on CentOS7 -

Create /etc/ssl/private directory

[root@myserver ~]# mkdir -p /etc/ssl/private

Copy your certificate file in /etc/ssl/private

[root@myserver ~]# cp myserver_example_com.crt /etc/ssl/private
[root@myserver ~]# cp myserver_example_com.key /etc/ssl/private/myserver_example_com.key

The next thing to do is to set up your websites virtual hosts to display the new certificate.

[root@myserver ~]# vim /etc/httpd/conf.d/ssl.conf
<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName myserver.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/private/myserver_example_com.crt
SSLCertificateKeyFile /etc/ssl/private/myserver_example_com.key
</VirtualHost>

Test your Apache configuration before restarting. To make sure that the syntax is correct, type:

[root@myserver ~]# apachectl configtest
Syntax OK

Restart the apache service -

[root@myserver ~]# systemctl start httpd.service

Verify on the browser -
https://myserver.example.com/

FREE Approach

The only difference between the PAID approach and FREE approach is here we no need to spend money on buying an SSl certificate from the trusted Certificate authoority.

When do we go with FREE Approach?

Free approach is nothing but having a self signed certificate.

Self-signed certificates or certificates issued by a private CA and are not appropriate for use with the general public.

Self-signed certificates can have their place:

• An Intranet. When clients only have to go through a local Intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
• A development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
• Personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connections.

Generate a Self-Signed Certificate from an Existing Private Key and CSR:
We have created an CSR and private key above in this article. Use them and create a self signed certificate.

[root@myserver ~]# openssl x509 -req -days 365 -in myserver_example_com.csr -signkey myserver_example_com.key -out myserver_example_com.crt
Signature ok
subject=/C=us/ST=california/L=milpitas/O=Example, Inc./OU=NOC/CN=myserver.example.com/emailAddress=root@myserver.example.com
Getting Private key

All other steps will remain same.

Verify on browser:
The only difference would be when you will open your website on the browser it will show a warning like this :

Go to advanced option and click on
Proceed to myserver.example.com (unsafe).

It will land you to the index page of your website.

It’s a lot of information. isn’t it! But I hope you won’t mind it because it will answer all the questions you might have regarding the understanding and implementation of SSL Eco System…

Hope you like the tutorial. Please let me know your feedback in the response section.

Thanks. Happy learning!