A brief overview of the TCP/IP model, SSL/TLS/HTTPS protocols and SSL certificates
By: Uday Hiwarale
Tags: Ssl, Internet, Cybersecurity, Security, Https

What are SSL certificates?

There are three principles of secure communication. Data Encryption, Data Integrity, and Data Authenticity. We have seen the first two so far. Data authenticity means the data is coming from the entity we are intending to communicate with.

When we access google.com in our browser, why are we so sure that a man-in-the-middle is not serving us the bad content? The man-in-the-middle could be using an HTTP server with public-private key cryptography, so is there any way to tell if our data is actually being sent to the google.com server?

When we access https://google.com , our browser communicates with the Google server with a suitable TLS protocol. The server responds with an SSL certificate that contains the public key of the server.

This SSL certificate is special, though its nothing but some binary data. This SSL certificate is digitally signed by an organization called Certificate Authority (CA) using its own private key.

Brower comes with preinstalled with CA public certificates. These are the certificates that the browser absolutely trusts, even blindly. There are two kinds of certificate authorities, the Root CA and the Intermediate CA. GlobalSign is one of the trusted root certificate authorities.

When google.com server sends the SSL certificate, it will be installed in the browser and it will look like below.

(google.com SSL certificate)

From the issuer information of the certificate, we can see that it was signed by the Google Trust Services. You can also see the public key information of google.com server in the Public Key Info section.

Since the SSL certificate of Google Trust Services was already installed in the browser, it could verify the digital signature contained in the SSL certificate sent by the google.com server. If a man-in-the-middle sends the wrong SSL certificate, our browser would complain about it since it is not signed by a certified CA.

You can also see the signature algorithm used to generate the digital signature of the SSL certificate. In the above example, the RSA algorithm is used in conjugation with SHA-256 to generate the digital signature of the certificate.

💡 Even if a man-in-the-middle sends the wrong SSL certificate which was indeed signed by a CA, the browser would not accept it since it would not contain the domain name of the website we are trying to access (google.com). CA verifies the background of a organizational before issuing a certificate.

If you are wondering if Google Trust Services is a part of the Google company then you are probably right. Does that mean it discredits the SSL certificates signed by them for their own purpose? Absolutely not.

Google Trust Services is an intermediate CA. Some organizations with a ton of websites and a ton of money would probably hesitate to contact a CA for certificate signing on daily basis. Instead, they become an intermediae CA and ask a root CA like GlobalSign to generate a certificate for them.

Using the private key of this signed certificate (which is kept private from a CA), it can sign other SSL certificates. What browsers have to do is to check for the parent CA of a certificate authority and verify the digital signature.

By walking up to the ladder up until the root CA, a browser can build a chain of trust. You can see this in the above screenshot. The GlobalSign is clearly the root CA of google.com and parent CA of GTS CA.

If any of the intermediate certificates fails, the whole trust chain fails and the website will be insecure to access or transmit data over. If everything checks out, a browser will show the green padlock icon in the status bar to indicate a trusted and secure connection.

(TLS 1.3 Handshake / source: Wikimedia Commons)

Not all browser comes with preinstalled intermediate certificates. Hence, instead of sending only one SSL certificate, a server may send a certificate bundle that contains an SSL certificate of its own and all the intermediate certificates. Only the root CA needs to be trusted to build the trust chain.

Certificate Generation Process

You can not create a certificate on your own, that’s the only rule. What you need to create is a public-private key pair and provide your public key to a certificate authority for signing and generating a certificate.

However, a standard process is to create a private key file first which ends with .key or .pem extension and create a certificate signing request file ending with .csr extension. This .csr file is then submitted to the CA.

The CA will take care of the process to generate a valid and trusted certificate. Once CA has gone through the CSR, it will validate your organization and then send a certificate file ending with .crt extension.

💡 This file may contain only one certificate asked for a particular domain name or a bundle of certificates which also include intermediate certificates.

Once you have your hands on the .cert file and the private key, you can configure your server to consume these files and provide a secure HTTP connection to the users who are trying to connect with your server using the HTTPS protocol.

Self-Signed Certificates

A self-signed certificate, as you can tell from the name is signed by yourself. If you are an intermediate CA, then this is the process you will follow to sell SSL certificates to your clients.

However, if you are not, then this doesn’t make any sense. When a browser downloads a self-signed certificate, it can not be linked to a valid root CA because the certificate was not signed by a trusted CA.

If a certificate is not accepted by the browser, that doesn’t mean the data is not being encrypted. You can absolutely communicate with a server securely despite some red SSL flags. But that’s not usually you should be doing.

If you have a self-signed certificate, you can install that certificate in your system/browser manually (as a trusted certificate) and the browser will stop complaining.

This also means that if you need to provide a secure and trusted communication channel for some people at your home, you can do that without having to go to a CA and pay a ton of money. Just that some people would need to work harder to make you happy.

Generating a Self-Signed Certificate

The certificate format used by the SSL/TLS protocol is X.509 developed by IETF. To generate an SSL certificate, we are going to use OpenSSL.

💡 OpenSSL is one of the most popular toolchains for TLS communication. It is also a command line interface (CLI) and toolkit to generate SSL certificates, private keys, CSRs and perform other kinds of cryptography operations.

First of all, we need a private key .key file and a certificate signing request .csr file. We are going to use the RSA cryptography to encrypt traffic on our server. To create these files, use the below command.

$ openssl req -new -newkey rsa:2048 -nodes -keyout thatisuday.key -out thatisuday.csr

The command above generates thatisuday.key file which is RSA 2048 bits private key file and a CSR in thatisuday.csr file which contains the matching public key.

This command asks for some input information about CSR among which Common Name is critical. This field basically tells the CA about the domain name for which a certificate has to be generated. You can also opt for a wildcard certificate.

(CSR Generation)

Now that we have a CSR, instead of submitting it to a CA, we are going to sign it ourselves using our own private key.

$ openssl x509 -req -days 365 -in thatisuday.csr -signkey thatisuday.key -out thatisuday.crt

The command above generates a thatisuday.crt certificate file that is self-signed, which also means that it has no root CA.

I am going to create a simple express server to launch an HTTPS server on Node.js. You can follow this program from the snippet below.

After the server is launched using node server.js command, you can go to a browser and access thatisuday.com . But before that, map thatisuday.com to the IPV4 loopback address (127.0.0.1) in /etc/hosts .

(https://thatisuday.com)

As you can see from the above screenshot, the Safari browser does not trust this website because it does not trust the certificate. To make this work, we need to install this certificate in our system and configure it.

(Install a certificate in MacOS)

By double-clicking on a certificate file or importing inside the Keychain Access application, you can install a certificate locally. Then you can double click on the certificate to modify its trust parameters.

(Modify trust parameters of a certificate in MacOS)

Once this process is complete, now your Safari browser can get the trust parameters of the certificate from the local system. Once you reload the browser, the website should start working normally.