How SSL Certificates Work: From Plain HTTP to Secure HTTPS
- Jayant Upadhyaya
- Jan 17
- 7 min read
Secure communication on the web is built on top of SSL/TLS certificates. A browser shows a small padlock icon near the address bar and indicates that a connection is "secure." Internally, a set of cryptographic steps and trust mechanisms ensure that data travels safely between client and server.
Understanding this process requires looking at three main topics:
The problem with plain, unencrypted communication
How symmetric and asymmetric encryption work together
How SSL certificates and certificate authorities solve the “who can be trusted” problem
The following sections walk through these concepts step by step.
1. Plain HTTP Communication and the Man-in-the-Middle Problem
On the internet, there are two primary actors in a typical web interaction:
Client – the user’s device or browser
Server – the machine hosting the website or API (for example, an Nginx or Node.js server)
In the simplest setup, the client sends an HTTP request to the server (for example, a GET request), and the server returns an HTTP response with HTML, JSON, or other content.
Client ---> HTTP Request ---> Server
Client <--- HTTP Response <--- Server
In plain HTTP, this communication is:
Unencrypted
Readable by anyone who can observe the network traffic
Between the client and server, there may be routers, Wi-Fi access points, or compromised devices. A malicious actor placed anywhere between them can capture or alter the data.
This is known as a Man-in-the-Middle (MITM) attack. In this situation, a hacker sitting between client and server can:
Read sensitive data (passwords, tokens, personal information)
Modify responses
Inject malicious content
To prevent this, the communication channel needs to be encrypted.
2. Symmetric Encryption: One Key for Both Locking and Unlocking
The most straightforward way to secure data is to use symmetric encryption.
A key is used to encrypt the data.
The same key is used to decrypt the data.
2.1. Basic Symmetric Encryption Flow
Original data (plaintext) exists on the client side.
A symmetric key is generated.
The data is encrypted using this key, producing ciphertext.
The ciphertext is sent over the network.
The server uses the same symmetric key to decrypt the ciphertext back to plaintext.
This approach is efficient and fast. However, there is a major problem:
The client and server must both have the same key, but the key itself must not be exposed to attackers.
If the client simply sends this symmetric key over the network to the server, a MITM attacker could copy it. Once the attacker has the key, all future encrypted communication can be decrypted.
This is known as the key exchange problem.
3. Asymmetric Encryption: Public and Private Keys
To solve the key exchange problem, cryptography introduces asymmetric encryption, also called public-key cryptography.
In asymmetric encryption:
Every participant has two keys:
A public key
A private key
The public key can be shared with anyone.
The private key is kept secret and never shared.
3.1. How Asymmetric Encryption Works
The roles of these keys are:
Public key: Used only to encrypt data
Private key: Used only to decrypt data previously encrypted with the matching public key
The public key cannot decrypt the data it encrypted. Only the corresponding private key can. This property makes it safe to send the public key over an insecure network.
4. Combining Symmetric and Asymmetric Encryption
In real-world HTTPS connections, symmetric and asymmetric encryption are combined:
Asymmetric encryption is used for secure key exchange.
Symmetric encryption is used for bulk data encryption, because it is faster.
4.1. Step-by-Step Key Exchange Using Asymmetric Encryption
Consider the server that wants to communicate securely:
The server generates a public key and a private key.
The public key is shared; the private key stays only on the server.
Now, when the client connects:
The server sends its public key to the client.
The client generates its own symmetric key (session key) locally.
The client encrypts this symmetric key using the server’s public key.
The encrypted symmetric key is sent to the server.
The server uses its private key to decrypt and recover the symmetric key.
At this point:
The client has the symmetric key (it generated it).
The server now also has the same symmetric key (it decrypted it).
A MITM attacker who intercepted the encrypted symmetric key cannot decrypt it, because only the server has the private key.
From this moment on, both client and server use the shared symmetric key to encrypt and decrypt all data. The communication is now confidential.
So, the key exchange problem is solved by using asymmetric encryption for exchanging the symmetric key.
5. Remaining Problem: Impersonation Without Certificates
The previous section assumes that the public key actually belongs to the real server. However, a MITM attacker can still perform a more advanced attack.
5.1. How a Man-in-the-Middle Can Impersonate the Server
Suppose:
The client requests the server’s public key.
A malicious actor sits between client and server.
The attacker can:
Intercept the server’s public key.
Generate their own public/private key pair.
Replace the real server’s public key with the attacker’s fake public key.
Forward this fake public key to the client.
Now the client believes this fake key belongs to the server.
What happens next:
The client encrypts its symmetric key using the attacker’s fake public key.
The attacker uses their private key to decrypt and read the symmetric key.
The attacker re-encrypts this symmetric key using the real server’s public key and sends it to the server.
Result:
The client thinks it talks securely to the real server.
The server thinks it talks securely to the legitimate client.
The attacker sits in the middle, decrypting everything and re-encrypting it, reading all data in clear form.
This is a successful man-in-the-middle impersonation attack, even with encryption.
Therefore, another question must be answered:
How can a client be sure that the public key it received truly belongs to the genuine server and not to an attacker?
This is where SSL certificates and certificate authorities come in.
6. The Role of SSL Certificates
An SSL certificate (more precisely, an X.509 certificate used by SSL/TLS) is a digital document that binds:
A domain name (e.g., example.com)
A server’s public key
to an identity, and it is digitally signed by a trusted authority.
The certificate answers the question:
“This is the public key for this exact domain, and a trusted third party confirms it.”
6.1. Certificate Authorities (CAs)
A Certificate Authority (CA) is a trusted organization that:
Verifies the identity of the certificate requester (the server owner).
Issues SSL certificates.
Signs certificates with its own private key.
Examples include providers like Let's Encrypt and others. Browsers and operating systems maintain a list of trusted CA public keys.
7. How an SSL Certificate Is Created
The typical process, simplified, works as follows:
The server generates a public/private key pair.
The server sends a Certificate Signing Request (CSR) to a CA, which includes:
The server’s public key
The domain name (e.g., example.com)
The CA verifies that the requester controls the domain.
The CA issues a certificate that contains:
The domain name
The server’s public key
Information about the issuer (CA)
Validity period
Other metadata
The CA then creates a digital signature over this data using its private key.
The signed certificate is returned to the server.
The server then installs this SSL certificate on its web server (e.g., Nginx).
8. What the Browser Does with the SSL Certificate
When a client (browser) connects to an HTTPS website, the following occurs:
The client connects to the server on port 443 (HTTPS).
The server sends:
Its SSL certificate (containing the server public key and CA signature)
The client examines the certificate:
Reads the issuer (which CA issued it).
Retrieves the CA’s public key from the browser or operating system’s trusted store.
The browser now verifies the certificate’s signature:
It uses the CA’s public key.
It checks whether the certificate contents produce the same signature.
If the signature is valid:
The browser confirms that:
The certificate was issued by a trusted CA.
The public key inside the certificate is associated with the stated domain.
If the URL in the browser matches the domain name in the certificate, the public key is trusted to belong to that domain.
If the signature is invalid or the issuer is unknown:
The browser warns that the connection is not secure or the certificate is not trusted.
9. Putting It Together: SSL/TLS Handshake Overview
Once the certificate is validated, the client can safely trust the server’s public key. The key exchange can now proceed securely.
A simplified view of the handshake:
Client connects to server and requests HTTPS.
Server sends its SSL certificate (with public key and CA signature).
Browser verifies:
Is the certificate from a trusted CA?
Is the certificate valid (not expired, not revoked)?
Does the domain name match the requested site?
If all checks pass, the client generates a symmetric session key.
The client encrypts this symmetric key using the verified server public key from the certificate.
Server decrypts the symmetric key using its private key.
Both now share the same symmetric key.
All subsequent communication between client and server is encrypted with this symmetric key.
A MITM attacker cannot:
Forge the server certificate without the CA’s private key.
Alter the server public key in transit without breaking the CA signature.
Thus, the attacker cannot successfully impersonate the server without being detected.
10. Self-Signed Certificates
It is possible for a server to create its own certificate and sign it with its own private key. This is known as a self-signed certificate.
Characteristics:
Useful for local development or internal testing
No external CA is involved
Browsers do not trust it by default
When a browser encounters a self-signed certificate:
It cannot validate it against any trusted CA.
It usually shows a warning such as “Your connection is not private” or “Certificate is not trusted.”
The encryption still works, but the identity of the server cannot be verified by the browser.
11. Why CAs Charge for Certificates
Certificate Authorities provide:
Identity verification services
Infrastructure to issue, sign, track, and sometimes revoke certificates
Security and availability for certificate management
These tasks require operational effort, auditing, and robust systems. Therefore, many CAs charge for certificates or related services. Some projects, such as Let’s Encrypt, provide certificates at no monetary cost but still operate significant infrastructure to do so.
Summary: How SSL Certificates Enable Secure Communication
SSL/TLS and SSL certificates together solve three major problems of web communication:
Confidentiality
All data between client and server is encrypted using symmetric keys.
Eavesdroppers on the network cannot read the content.
Integrity
Data cannot be altered in transit without detection.
Authentication
Browsers verify the server’s identity using SSL certificates signed by trusted CAs.
This prevents attackers from impersonating the server and performing man-in-the-middle attacks.
The complete process can be summarized as:
Asymmetric cryptography enables safe key exchange.
Symmetric cryptography enables efficient data encryption.
SSL certificates, issued and signed by trusted Certificate Authorities, bind public keys to domains and allow clients to verify that they are talking to the correct server.
This combination creates the secure HTTPS connections used by modern websites and applications.
Comments