SSL Certificates Explained: Everything You Need to Know in One Go

9 min readApr 24, 2024

Secure Sockets Layer (SSL) certificates are pivotal in ensuring the security of data transmitted across the internet. By encrypting information sent between a user’s browser (client) and the website’s server, SSL certificates prevent unauthorized access and protect data integrity. This article demystifies how SSL certificates work, making the concept accessible even for those with little technical background.

Section 1: Basics of Internet Communication

In any internet interaction, there are two main players: the client (e.g., your browser) and the server (where websites are hosted). These two need a secure way to communicate to prevent sensitive information from being intercepted by third parties.

The Need for Encryption: Encryption is the process of encoding information in such a way that only authorized parties can access it. It is essential for protecting data integrity and confidentiality during transmission.

Section 2: Understanding Encryption

Symmetric Encryption: This method uses a single key to both encrypt and decrypt data. The simplicity of symmetric encryption makes it fast and efficient but poses a significant challenge: the key distribution problem. If a third party intercepts the key during its exchange, they can decrypt the data, leading to potential data breaches.

Limitations of Symmetric Encryption

The biggest challenge is key exchange. If a third party intercepts(often called Man in the Middle Attack) the key during exchange, they can unlock the box, compromising security.

Asymmetric Encryption: To address the limitations of symmetric encryption, asymmetric encryption uses a pair of keys — a public key and a private key. The public key is available to everyone but can only encrypt data. The private key, which is kept secret by the owner, is used to decrypt data. This method solves the key distribution problem but is computationally heavier.

Real-World Analogy: Compare it to a mailbox where anyone can drop in mail (public key) but only the owner has the key to open it (private key).

Key Exchange Mechanism

When a client connects to a server, it encrypts data using the server’s public key. This data can only be decrypted by the server’s private key.

How a Man-In-The-Middle Attack Works with Asymmetric Encryption

Interception: The attacker positions themselves between the client (e.g., a user’s browser) and the server (e.g., a website). This positioning is crucial as it allows the attacker to intercept all communications between the two parties.
Public Key Deception: When the server sends its public key to the client to establish a secure connection, the attacker intercepts this public key and instead sends a counterfeit public key to the client. The client, unaware of the interception, receives and uses this counterfeit key thinking it is legitimate.
Data Manipulation: The client then encrypts the data using the counterfeit public key provided by the attacker and sends it back across the network. Since the data is encrypted with the attacker’s public key, the attacker can decrypt it using their corresponding private key.
Re-encryption and Forwarding: After decrypting the intercepted data, the attacker can read and modify the information if they choose. They then re-encrypt the data using the legitimate public key of the server and send it to the server. The server, unaware of this interception and modification, decrypts the data with its private key and processes it.
Response Interception: Similarly, any data sent from the server to the client can be intercepted, decrypted, modified, and re-encrypted by the attacker before being sent to the client.

Why Does This Attack Succeed?

Lack of Authentication: The key vulnerability here is the lack of authentication of the public key. The client has no inherent way of verifying whether the received public key actually belongs to the legitimate server unless a trusted third party or mechanism is in place (such as digital certificates from a trusted Certificate Authority, CA).
Trust Assumption: Clients and servers typically assume that the public key exchange has not been tampered with, which is not a safe assumption in insecure networks.

Mitigations

Section 3: How SSL Certificates Use Asymmetric Encryption

Key Exchange Mechanism

SSL certificates utilize a hybrid encryption system combining the best features of both symmetric and asymmetric encryption. Here’s how it works:

Asymmetric Encryption Start: When a client initially connects to a secure server (one that uses SSL/TLS), the server presents its SSL certificate, which includes the server’s public key.
Session Key Creation: The client then generates a random session key for the current interaction session. This session key will be used for symmetric encryption, which is more efficient than asymmetric encryption for ongoing data transfer.
Encrypting the Session Key: The client encrypts this session key using the server’s public key (from the SSL certificate) and sends it back to the server.
Decrypting the Session Key: Only the server has the corresponding private key to decrypt the session key sent by the client.
Symmetric Encryption Commences: From this point, both the client and the server use the session key for symmetric encryption of their communication, ensuring a fast and secure transmission.

Protecting Against MITM Attacks

SSL certificates play a crucial role in preventing Man-In-The-Middle (MITM) attacks:

Authentication: The SSL certificate provides proof of the server’s identity to the client. By verifying the certificate, the client can be sure that the public key used to encrypt the session key actually belongs to the legitimate server and not to an attacker posing as the server.
Establishing a Secure Channel: Once the session key is securely exchanged and symmetric encryption is established, the encrypted channel protects against eavesdropping and tampering by third parties.

Section 4: Role of SSL Certificates

Obtaining an SSL Certificate

The process of obtaining an SSL certificate from a Certificate Authority (CA) involves several steps:

Generating a Key Pair: The server generates a private key and a public key.
Certificate Signing Request (CSR): The server creates a CSR, which includes the server’s public key and identity information (like the domain name, company name, etc.).
CA Validation: The CA verifies the server’s identity, which can vary in thoroughness depending on the type of SSL certificate. Once verified, the CA creates an SSL certificate containing the server’s public key and signs it with the CA’s private key.
Issuance and Installation: The signed SSL certificate is sent back to the server, where it is installed.

Digital Signatures and Trust

Digital signatures ensure the integrity and authenticity of the SSL certificate:

Trust Chain: The CA’s signature on the SSL certificate establishes a trust chain. Clients trust the SSL certificate if they trust the CA, which is established by having the CA’s root certificate pre-installed in web browsers and operating systems.

Section 5: Validating SSL Certificates

Certificate Verification

Upon establishing a connection, the client performs several checks:

Certificate Validity: The client verifies that the SSL certificate has not expired.
CA Signature: The client uses the CA’s public key (from a trusted root CA certificate in its trust store) to verify the signature on the SSL certificate.
Domain Match: The client checks that the domain name on the certificate matches the domain it is connecting to.

Ensuring Integrity and Authenticity

If all checks pass, the client can confidently encrypt data with the server’s public key, knowing that the encrypted data can only be decrypted by the private key held securely by the server.

Example of Medium.com’s SSL Certificate:

There are numerous Certificate Authorities (CAs) around the world, each authorized to issue digital certificates that help secure communications over the internet. These CAs vary widely in size, services, and regional focus. Here is a brief overview of some well-known CAs:

1. DigiCert

One of the most prominent CAs, known for high-assurance certificates and a wide range of SSL certificate options. DigiCert acquired Symantec’s security business, further expanding its portfolio.

2. Let’s Encrypt

A free, automated, and open Certificate Authority provided by the Internet Security Research Group (ISRG). It is known for democratizing SSL certificates with its easy-to-use, automated processes that encourage widespread adoption of HTTPS.

3. Comodo CA (now Sectigo)

This CA offers a variety of security solutions including SSL certificates, comprehensive web security services, and more. It’s one of the largest providers of SSL certificates.

4. GlobalSign

GlobalSign is a well-established CA that provides digital identity and security solutions. They offer a range of SSL certificates, including scalable solutions for small and large enterprises.

5. GoDaddy

While primarily known as a web hosting and domain registration company, GoDaddy also offers SSL certificates, making it a convenient choice for businesses already using their hosting services.

6. Cloudflare

Cloudflare provides a service called Universal SSL, which automatically enables SSL security for websites using its services. This feature provides an SSL certificate at no additional cost for all Cloudflare customers, effectively enabling HTTPS for millions of websites.
For the Universal SSL service, Cloudflare partners with multiple traditional CAs to issue SSL certificates. These CAs include well-known entities like DigiCert and Comodo. This means that while Cloudflare itself is not directly issuing these certificates, it facilitates their issuance through its partnerships.

Creating SSL Certificates for Development Websites (Localhost):

Creating SSL certificates for localhost-hosted websites is a common requirement during development and testing phases. It allows developers to ensure their applications work correctly over HTTPS, just as they would in a production environment. Here’s a step-by-step guide on how you can create and use SSL certificates for localhost:

1. Use a Development CA like mkcert

mkcert is a simple tool that makes it easy to create valid SSL certificates for your local development environments, which means no more browser warnings. Here’s how to use it:

Step 1: Install mkcert

Install mkcert by following the instructions on its GitHub page. It is available for macOS, Linux, and Windows.
You might need to install the certutil tool if you don’t have it already (for example, via brew install nss on macOS).

Step 2: Setup the Local CA

Run mkcert -install. This command sets up mkcert on your machine and installs a local CA (Certificate Authority) in the system trust store, which your browser and operating system will trust.

Step 3: Create the Certificate

Navigate to the directory where you want your certificates stored.
Run mkcert localhost or any other domain names you need for your development environment, like mkcert example.local 127.0.0.1 ::1. This generates the certificate and key files for you.

Step 4: Configure Your Web Server

Use the generated files in your server’s SSL configuration. For instance, in an Express.js application, you might configure your HTTPS server like this:

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('path/to/key.pem'),
  cert: fs.readFileSync('path/to/cert.pem')
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end("hello world\n");
}).listen(8000);

2. Self-Signed Certificates

You can manually create a self-signed SSL certificate using OpenSSL, which is a robust tool available on most Unix-based systems (including macOS and Linux) and also on Windows.

Step 1: Generate a Private Key

openssl genrsa -out localhost.key 2048

Step 2: Generate a CSR (Certificate Signing Request)

Create a CSR using the private key. You will be prompted to enter your domain and contact information.

openssl req -new -key localhost.key -out localhost.csr

Step 3: Generate the SSL Certificate

Create the SSL certificate valid for a specified number of days.

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