SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) is a security protocol that works to provide the secured connection between two internet nodes. It works in the application layer. SSL Cert works on HTTP and URL/link protocol becomes HTTPS.This article describes the following topics to give an general overview of the SSL and SSL certificates.
Getting and Installing SSL Cert
SSL is mainly used to provide secured connection between a server and a server-client (web browser). SSL Certificate is a certificate that ensures that the communication between the server and the client is protected against: eavesdropping and alteration. There are some known certificate providers that clients can trust: DigiCert, GeoTrust, GlobalSign, GoDaddy, and so on. You can write your own certificate and set your browser trust that certificate. There are some generic steps to get and install the SSL certificate (a text file with encrypted data) in your server. I am providing only the conceptual steps below. For specific steps and diagnostic tools, please consult your server manual and the SSL certificate provider.
Create a CSR (certificate signing request):
You can use OpenSSL or other server/SSL certificate provider tool to create the CSR. You need server URL, organization details (name, location, etc), key type and key size. Usually, two files (.csr, and .key) will be created in the process. You will need .key to install the certificate in the server and send the .csr file to SSL certificate provider during the purchase.
Purchase the certificate from a SSL certificate provider using the .csr file.
The provider will check your organization\’s authenticity before issuing the certificate. Some providers provide intermediate certificate to establish the authenticity of the SSL cert by tying your cert with the provider’s root cert.
Install the cert.
Please consult your server manual to complete the installation. Some providers have their verification tools to test the installation. Otherwise, if everything is fine, you can easily verify the successful installation using a browser.
Working Principle of SSL
After you are done with the setup, users can use your site using the HTTPS protocol. There are several message transfers between the client (i.e. browser) and the site server as described below.
Client Hello Message
First, the client sends a Hello message to the server containing:
Version Number: The highest number that the client supports.
Random Data: It consists of the client’s 4-byte date and time plus a 28-byte randomly generated number (total 32 byte).
Session ID: This info is included if the client wants to resume a previous session.
Cipher Suite: List of cipher suites available on the client.
Compression Algorithm: The requested compression algorithm (none supported or used as of 20 May, 2016).
The server sends back the the following messages in response to the client’s Hello message:
Server Hello Message:
Version Number: The lower of: the highest version number the server supports and the highest version number the client supports.
Random Data: It consists of the server’s 4-byte date and time plus a 28-byte randomly generated number (total 32 byte).
Session ID: It is one of the following three:
New session ID – The server generates new ID when:
No session ID in the client message OR
The server can’t resume the session indicated by the client
Session ID as indicated by the client – The server can resume the session.
Null – The server will not resume the session.
Cipher Suite: The strongest cipher that both the client and server support. If there are no such suite available, the communication drops with the “handshake failure” alert.
Compression Algorithm: The compression algorithm none supported or used as of 20 May, 2016).
Server Certificate: The certificate contains the public for the domain. The client checks the name of the server and the public key in the certificate to authenticate the server.
Server Key Exchange: When the public key algorithm does not provide the public key, the server creates and sends a temporary key to the client.
Client Certificate Request: This is required when the server needs to verify the client’s authentication (e.g. banking using your mobile app).
Server Hello Done: This message indicates that the server is finished and awaiting a response from the client.
Client Response to Server
Client Certificate: If the server sent a Client Certificate Request, the client sends its certificate containing its public key to the server for the client authentication.
Client Key Exchange:
There are two components:
The client computes the session key using both random values and then encrypt it using the public key.
This message will also include the protocol version. The server will verify that it matches the original value sent in the client hello message. This measure guards against rollback attacks. Rollback attacks work by manipulating the message in order to cause the server and the client to use a less secure, earlier version of the protocol.
Certificate Verify: This message is created by encrypting all messages upto this point using the client’s private key only if the client sent a Client Certificate to the server. The server verifies the client using the public key of the client.
Change Cipher Spec: This message notifies the server that all messages that follow the Client Finished (as mentioned next) message will be encrypted using the keys and algorithms just negotiated.
Client Finished: This message is created by encrypting all messages upto this point using the server’s public key to provide further authentication of the client.
Server Final Response to Client
Change Cipher Spec Message:
This message notifies the client that the server will begin encrypting messages with the keys just negotiated.
Server Finished Message:
This message is created by encrypting all messages upto this point using the session key. For added security, the encrypted message is further encrypted using the message authentication code (MAC).
If the client is able to successfully decrypt this message and validate the contained hashes, it is assured that the SSL/TLS handshake was successful.
Because public key encryption technique takes a lot of processing power, they are only used during the SSL Handshake to create a symmetric session key. In the above discussion, I mentioned the session key creation only once by the client. But the server also creates the session key locally and it must match with the session key generated by the client. After the secure connection is made, the session key is used to encrypt all transmitted data.
 SSL Certificate Reviews – SSL Comparison. 2008. https://www.sslshopper.com/certificate-authority-reviews.html
 OpenSSL. 2003. https://www.openssl.org/
 SSL/TLS in Detail – TechNet – Microsoft. 2015 https://technet.microsoft.com/en-us/library/cc785811(v=ws.10).aspx
 Message authentication code – Wikipedia, the free encyclopedia. 2011. https://en.wikipedia.org/wiki/Message_authentication_code
 Public-key cryptography – Wikipedia, the free encyclopedia. 2011. https://en.wikipedia.org/wiki/Public-key_cryptography
 What Is SSL (Secure Sockets Layer)? | DigiCert.com. 2005. https://www.digicert.com/ssl.htm