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.
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.
The Session layer of the OSI model is responsible for creating the connection and validating the webserver. If you want to know more about the OSI model, check out my blog: https://www.thegeekyminds.com/post/7-layers-of-the-osi-model-explained
What is included in an SSL/TLS certificate?
An SSL/TLS certificate contains the following information.
Domain name
Certificate authority
Certificate authority's digital signature
Issuance date
Expiration date
Public key
SSL/TLS version
Who needs an SSL/TLS certificate?
Why are SSL/TLS communications important?
If you own a website, you may be wondering - "Do I need an SSL /TLS certificate for my website?"
You will have the following benefits if you use an SSL/TLS certificate for your website -
Having an SSL certificate means you're protecting your company, its customers, and its data from fraudsters and other malicious entities. There are also other benefits to getting a certificate - it makes sure they include things like GDPR compliance.
Customers may pull out of a website that doesn't have the padlock icon and the HTTPS protocol. Nowadays, with browsers giving warnings on sites that use only HTTP instead of HTTPS, it's not worth the risk to use unsecured connections.
A lot of people ignore the importance of SSL certificates, but having SSL/TLS certificates can help you get better rankings on search engines, improve your conversion rate & make customers feel safe.
Having said all of this, you may wonder - "How long are SSL certificates valid?"
What is the maximum SSL/TLS certificate validity period?
All the certificates have a maximum validity period of 397 days which basically translates to 13 months. This shorter validity period of the SSL/TLS certificates strengthens the security of browser-to-server communication. The longer the validity the higher the risk.
Types of SSL Certificates
SSL certificates can be categorized by the validation levels and the number of domains they secure
Classification by Validation Levels
Domain Validated certificate
Domain-validated (DV) certificates (SSL/TLS Certificate) require the least validation, as their main purpose is to securely connect a website’s web server and browser. They also cost the least. The Certificate Authority (CA) simply verifies that the owner controls the domain.
It does not provide information related to the owner's business, hence does not provide high assurance to its users. It is applicable for information-giving sites like blog sites but not applicable for sites where you put personal information or make payments.
Organization Validated Certificates
The Organization Validated (OV) certificate (SSL/TLS Certificate) is a well-known form of validation. It checks that an organization has the right to use the domain. The Organization Validated (OV) certificate enhances the trust level of the organization and helps establish its credibility.
The Organization Validated (OV) certificate is used mostly on commercial business sites to build trust among its consumers.
Extended Validated Certificates
The Certificate Authority (CA) conducts rigorous vetting to validate that the organization behind the Extended Validated (EV) certificate (SSL/TLS Certificate) is verified with a background check. This includes verifying its legal, physical, and operational existence as well.
These certificates are mostly used by websites where users provide sensitive information like very personal information and payment details.
Classification by the Number of Domains it secures:
Single Domain Certificate
A Single Domain Certificate is an SSL/TLS certificate that secures only one fully qualified domain or subdomain name (not both).
For example: With this type of SSL/TLS certificate, you can secure either https://gourav-dhar.com or https://blogs.gourav-dhar.com but not both
Wildcard SSL Certificate
Wildcard certificates (SSL/TLS Certificates) are used to secure a single domain name and all its subdomains as well.
For example: With this type of SSL/TLS certificate, you can secure both https://gourav-dhar.com and https://blogs.gourav-dhar.com
Multi-Domain SSL Certificate
The Multi-Domain SSL certificate is a special certificate that secures multiple domains with the help of the SAN extension. It is known for being able to secure the Microsoft Exchange and Office Communication environment.
For example: With this type of SSL/TLS certificate, you can secure - https://gourav-dhar.com, https://blogs.gourav-dhar.com, https://thegeekyminds.com
Differences between SSL and TLS certificate
Till now I have talked about SSL and TLS being certificates issued by the Certificate Authority. But there are certain differences between these cryptographic protocols.
SSL
A Secure Socket Layer, or SSL, was created by Netscape in 1994 as a way of making sure that communications between clients and servers remain secure. Originally, it was envisioned as a system for web-based communications. Eventually, it was picked up by the IETF to establish standards for security.
There have been two versions of SSL since the one that overcame the weaknesses found in version 1. The newest one is SSL 3.0, which was significantly strengthened to protect online data with uncompromised security levels.
The Internet Engineering Task Force (IETF) published the final draft of SSL 3.0 in 1996. (Pretty old!)
TLS
Christopher Allen and Tim Parkes of Consensus Development wrote the TLS 1.0 protocol, the updated version of SSL 3.0. Although there was a name change, there wasn’t a significant difference between both.
The reason for the change in name, according to Dierks, was a face-saving gesture by Microsoft. An excerpt from his writing.
“As a part of the horsetrading, we had to make some changes to SSL 3.0 (so it wouldn’t look the IETF was just rubberstamping Netscape’s protocol), and we had to rename the protocol (for the same reason). And thus was born TLS 1.0 (which was really SSL 3.1). And of course, now, in retrospect, the whole thing looks silly.”
There are 4 versions of TLS. TLS 1, TLS 1.1, TLS 1.2, TLS 1.3
Both the TLS and SSL certificates essentially serve the same purpose. Both of them are X.509 digital certificates that help encrypt data that is sent between servers in a handshake process and create a secure connection. SSL and TLS are related but not the same. SSL today is obsolete and TLS is widely used. But people still use both SSL and TLS interchangeably as there is not much significant difference between them. They have minor differences between them. To know more about the differences between SSL and TLS, check out these two links.
How do I view the SSL certificate in Chrome, Firefox, and Safari
A lot of people read the sticker before they buy food, or before taking some medicine. It's a precautionary measure for what you are consuming is actually safe. The internet is no different. So if you come to a website, it's good to read the sticker and see if it's what you expected!
You would ask - “Hey Gourav, Where’s a sticker on a website?”
It’s the SSL certificate.
Don't know how to do that? That's perfectly normal. Sadly, the majority of people don't either. However, checking SSL certificate details should be a priority when visiting a new website. This can help ensure that no one is spying on what you're browsing and keep your data safe from thieves who want to steal it.
Let's say I want to view the SSL certificate of: https://www.thegeekyminds.com
I will open the webpage on the desired browser
How to view the SSL certificate on Google Chrome?
1. On the address bar, click on the padlock icon - the icon with the lock symbol on the left side of the URL
2. Click on "Connection is secure"
3. Click on "Certificate is valid" to view the certificate
How to view the SSL certificate on Firefox?
1. On the address bar, click on the padlock icon - the icon with the lock symbol on the left side of the URL
2. Click “Connection secure” -> then click "More information"
3. Under Security, click View Certificate to view the certificate
How to view the SSL certificate on Safari?
1. Click the address bar
2. Click the padlock icon (looks like a lock) on the left side
3. Click “Show Certificate”
4. Click the drop-down arrow to view full certificate details.
Conclusion
A website's SSL/TLS certificate provides a level of trust to the user, prevents attacks on the site, and makes sure that their data is safe. SSL/TLS certificates provide assurance that you are securely communicating with the correct website. This helps prevent spoofing, man-in-the-middle attack, and other kinds of cyber attacks. SSL is obsolete and no longer used today. TLS, the successor of SSL is widely used but both these terms are often used to refer to the same thing.
Now that you know all about SSL/TLS Certificates and how they secure your connection with the webservers, drop a comment if you liked this blog.
And that's a wrap! Hi, I am Gourav Dhar, a software developer and I write blogs on Backend Development and System Design. Subscribe to my Newsletter and learn something new every week - https://thegeekyminds.com/subscribe
_edited.png)
Love how you broke down SSL/TLS! But man, it's wild how so many folks overlook the physical side of security. I mean, you can have all the SSL/TLS certs you want, but without solid encryption on the actual hardware, there’s still a risk, right? Ever looked into something like the iStorage diskAshur3 at https://www.datawaysecurity.com/encrypted-ssds-hdds/134-istorage-diskashur3.html ? It’s got hardware encryption that would seriously back up everything you explained here. Imagine pairing that with SSL/TLS – now THAT’s bulletproof security!