top of page
Programming

What is an SSL/TLS Certificate and How do they Secure Your Website? - Backend Development Series

Updated: Dec 9, 2022



Why is it safe to give your personal information on one website and not another? What makes one website safer and more secure than another? How can buyers be certain that a company's website is a place where they can securely check out? Actually, there are various things going on behind the scenes to make sure everything you browse on the internet is protected and secure.

Everything boils down to Certificate Authorities and SSL/TLS encryption. It ensures that communication over the internet is kept private.


If you are someone who is interested to know about Certificate Authorities, and SSL/TLS certificates - what are they and how they help to create a secure communication between your browser and the web server, this blog is for you.


Let's dive right in -


What is a Certificate Authority?

Certificate authorities are third-party companies that issue digital certificates to users to verify the identity of a server. When you visit a website secured with SSL or TLS, the browser looks for a valid certificate from one of these authorities and if it can't find one, it alerts you.


If this doesn't make sense now, it's fine, we will deep dive into it below.

What are SSL/TLS Certificates?

An SSL/TLS Certificate is a type of digital certificate issued by the Certificate Authority that establishes encrypted links between a web server and a web browser. It is used to protect the confidentiality and integrity of data being transferred over the internet.


To put it simply, the SSL/TLS certificate provides an identity for your website, meaning that it cannot be impersonated by anyone else. It plays an important role to encrypt the traffic between your site and your visitors so nobody can see what they are sending or receiving.


TLS is the successor of the SSL/TLS protocol and is used in modern systems. Even though there are differences between SSL and TLS, they are often interchangeably used to mean the same thing.


SSL stands for Secure Sockets Layer

TLS stands for Transport Layer Security


You may be wondering -"Okay Gourav, enough with the definitions, what exactly are these SSL/TLS certificates and how do they guarantee secure communication?"


Let's look at it.


How do SSL/TLS certificates work?

How do the SSL/TLS certificates secure your website? Why are SSL/TLS certificates required in the first place?


Imagine you are a user, browsing a website. You make a request to the web server with some personal details in the body of the request. You don't want this request to be sent in plain text and unencrypted form. Anyone can sniff the network packets to find out what is present in the request body.


So how do I encrypt this request body?


In cryptography, there are 2 types of encryption - Symmetric Encryption and Asymmetric encryption.


In Symmetric Encryption, the same key encrypts and decrypts the data.

For our use case, we will use this symmetric key to encrypt the data being shared. Now that we have this key, you may say - "Okay great, make two identical copies of this key and share these with the user and web server. The user will encrypt his data using the key, and the server will decrypt this data using its own copy of the same key."


Well, there's a fundamental problem with this logic. How do you create a key and share these 2 identical keys "safely" with both the user and the server? "Safely" being the keyword here.


You can see in the above image, the user tries to send the symmetric key to the server but the person in the middle can see the key and use it to decrypt future network packets. This person who is the sniffer may intercept the routers to sniff user data.


So this method of symmetric key sharing alone won't solve the problem. The user can't directly share the key with the server. Some level of encryption needs to be done here too. (By the way, this symmetric key is also known as the session key.)


This is where Public Key Cryptography comes in -

In this method, there are 2 keys, Public Key and Private Key. Anyone with the public key can encrypt the information, and only the private key can decrypt it.

Basically something like this.


Image Source: https://www.twilio.com/blog/what-is-public-key-cryptography


The server will have a pair of public and private keys.


Now the user tells the server - "Hey, let's connect!"

The server responds - "Yep, sure. Here's my public key"


The client/user then encrypts its symmetric key using the public key that the server gave and sends it over to the server.

The server now decrypts the information using its private key to get the symmetric key.


The public key can be shared with everyone publicly. The idea is the server shares its public key with the client. The client then encrypts the data. Since the public key can't decrypt the data, it's safe even if someone has the public key. Only the server can decrypt the data with its private key.


If anyone sniffs the encrypted key, they can't decrypt it because they won't be having the private key to decrypt it.


But, there's a problem with this too.


How does the user know that the public key actually which was sent to him/her, actually belongs to the server and not someone present in the middle sniffing the packets?


Let's say the man-in-the-middle has his own public and private key pair. He sends us his public key, and we encrypt our symmetric key and give it to him. He uses his private key to decrypt it. This way the man in the middle gets our symmetric key and then he sends it over to the server (by impersonating us) and encrypts it using the server's public key.




There should be a way for the user to verify that the public key received by the user actually belongs to the web server with which it wants to connect to and not a man in the middle.


This is where the Certificate Authority comes in. A Certificate Authority is a third-party authority that verifies the authenticity of the public key. Whenever a new server is set up, it contacts the certificate authority to create a certificate for its public key. The certificate authority signs this certificate.


Basically, the certificate will have the web server name, the public key, and its signature (signed by the certificate authority).


Now you may ask - "How do I trust the signature, can't it be faked?"


Well, the signature is actually the public key of the webserver that has been encrypted by the private key of the certificate authority.

Yes, the certificate authority also has its own public and private key!



There's another certificate for the public key of the certificate authority which is signed by another certificate. There is actually a chain of such certificates until there's a root certificate.


When the client sends a request to the webserver, the webserver responds back with this chain of certificates. The client will then verify that the certificate is actually valid. And then encrypt its symmetric key with the public key of the server and send it over. This process is also called SSL Handshake.


It is depicted in the diagram below. It is done only once to exchange the symmetric key. This symmetric key is also known as the session key. After a secure connection is established, this session key is used to encrypt further data.



How will the client verify the chain of certificates?

The client/user (which is basically you) will use the public key of the Certificate Authority to decrypt the signature in the certificate of the web server. If it matches the public key present in the certificate, it means that the certificate can be trusted. Since there is a chain of such certificates, the client will verify the certificates until it reaches the root.


The root certificate is actually self-signed. It doesn't have a parent, so obviously, no one else's signature is present on it.


You may wonder - "How do you trust a certificate which is self-signed"


Here's a big reveal!


The root certificate is actually present on your machine - The user's machine.

If your root certificate has expired or is invalid, it will show you `NET::ERR_CERT_INVALID`




It is almost impossible for anyone to replicate this chain of certificates. This way the Certificate Authority plays an important role in web security.


SSL and TLS are types of these digital certificates issued by the Certificate Authority.

The most crucial element of SSL/TLS is that it's digitally signed by a trusted Certificate Authority (CA). Anyone can create a certificate, but browsers will only trust certificates if they come from an organization on the list of its trusted Certificate Authorities (CAs). Browsers come with a pre-installed list of trusted Certificate Authorities (CAs), known as the Trusted Root Certificate Authority (CA) store. In order to be added to this list and thus become a trusted Certificate Authority, companies must comply with strict security and authorization guidelines created by the browsers.


What is SSL Pinning?

The process of associating the web server with its public key using a certificate is commonly called SSL Pinning. We pin the public key to the web server, hence it is named SSL Pinning.


Well enough of the story, let me summarise the above into concise and direct points.


SSL/TLS Handshake

  • The browser opens a connection with the webserver and asks for the public key and SSL/TLS certificates.

  • The server replies with its public key along with SSL/TLS certificates signed by the Certificate Authority (CA). This signature is basically the public key of the server encrypted using the private key of the Certificate authority.

  • The certificate Authority (CA) will have a certificate for its own public key, and there will be a chain of such certificates until the final certificate will be the one stored in the local machine of the user.

  • When the user/browser receives this chain of certificates and public keys, it will verify the public key. Upon successful verification, it will encrypt the symmetric key (also called the session key) using the public key of the server.

  • The server will decrypt the message using its private key to retrieve the symmetric key (aka the session key).

  • Now both the client and server have the same symmetric/session key

  • For all future communications, the server and the browser will encrypt the information using the symmetric key (session key) and the other end can decrypt the information using its own copy of this session key

Voila! The messages can now be safely shared without worrying about anyone sniffing in the middle.