Understanding SSL, TLS, and Certificates: A Practical Deep Dive - For the Nerds

Encryption is one of the foundations of modern internet security. Every time you type a URL into your browser and press enter, an incredible amount of cryptographic and networking magic happens in just a few milliseconds. This article is a step-by-step walkthrough of how it all works — without analogies, just straight technical detail in a clear, expository flow.

1. What Is “The Network”?

When data moves between your device and a server, it doesn’t travel in a straight line. Instead, it hops through a series of interconnected systems:

• Your local router and access point
• Your Internet Service Provider’s (ISP) infrastructure
• Regional and international backbone routers
• Data centers, switches, and gateways

This interconnected system of devices and links is what we call the network. Each device along the path forwards your data closer to its destination. Historically, the data was transmitted in plaintext, which meant every intermediary system could inspect or tamper with it. This is why encryption became essential.

2. The Journey of a Typical HTTPS Request

When you type https://example.com into your browser, here’s what happens:

1. DNS Resolution

   • Your system queries a DNS resolver to map the domain name (example.com) to an IP address (e.g., 93.184.216.34).
   • Depending on your configuration, this query may go through your ISP, a public DNS provider (like Google’s 8.8.8.8), or Cloudflare’s 1.1.1.1.
   • Traditionally DNS runs on UDP port 53 and is not encrypted. Modern DNS can use DNS over HTTPS (DoH) or DNS over TLS (DoT) for confidentiality.

2. TCP Handshake

   • Your client establishes a connection to the server’s IP on port 443.
   • This uses the classic 3-way handshake: SYN → SYN-ACK → ACK.
   • At this point, a communication channel is open but not yet encrypted.

3. TLS Handshake

   • The server presents its TLS certificate.
   • The client validates the certificate by:
     • Checking that it is signed by a trusted Certificate Authority (CA).
     • Ensuring the certificate matches the requested domain name.
     • Verifying the validity period (not expired).
     • Optionally checking revocation status (via CRL or OCSP).
   • If valid, the client and server agree on encryption parameters and derive a session key.
   • From here, all communication is encrypted with symmetric cryptography.

4. HTTP Request Over TLS

   • Your browser sends the actual HTTP request (e.g., GET /) through the encrypted tunnel.
   • The server processes the request and returns an encrypted response.

This entire process takes only milliseconds.

3. Why the Client Verifies Certificates

Certificate validation is the responsibility of the client. The reason is simple: the client needs to ensure it is talking to the genuine server and not an attacker impersonating it. Without this validation step, a man-in-the-middle attack would be trivial.

The server has no reason to verify its own identity, it already knows who it is. The client must perform the verification to establish trust.

4. Certificate Authorities (CAs)

Certificates are issued by Certificate Authorities (CAs), globally recognized organizations that browsers and operating systems trust by default. Examples include DigiCert, GlobalSign, Let’s Encrypt, and Google Trust Services.

Certificate Issuance Process

1. Key Pair Generation
   The server owner generates a public/private key pair.

2. Certificate Signing Request (CSR)
   The public key and identifying information (domain, organization, etc.) are bundled into a CSR.

3. Validation by the CA

   • Domain Validation (DV): The CA verifies that the requester controls the domain (via DNS records or HTTP challenges).
   • Organization Validation (OV): The CA verifies organizational details.
   • Extended Validation (EV): The CA performs strict business and legal checks.

4. Certificate Issuance
   The CA signs the certificate using its private key. The certificate is then chained up to a root CA already trusted by browsers/OS.

5. Deployment
   The server installs the signed certificate. During a TLS handshake, this certificate is presented to clients.

5. DNS and Encryption

DNS is often the first step in any connection but traditionally was unencrypted. This meant anyone on the path could see which domains a client was resolving. Modern improvements include:

• DNS over HTTPS (DoH): DNS queries tunneled through HTTPS.
• DNS over TLS (DoT): DNS queries sent over TLS on port 853.
• DNSSEC: Adds cryptographic signatures to DNS records to ensure authenticity (but does not encrypt queries).

When using DoH or DoT, a TLS handshake occurs between the client and the DNS resolver, just like with any HTTPS server.

6. SSL vs TLS

The terms SSL and TLS are often used interchangeably, but they are not the same.

• SSL (Secure Sockets Layer):

  • Developed by Netscape in the 1990s.
  • SSL 2.0 and SSL 3.0 are obsolete and insecure.

• TLS (Transport Layer Security):

  • Introduced in 1999 as the successor to SSL.
  • Modern versions are TLS 1.2 and TLS 1.3.
  • TLS 1.3 is the latest, offering faster handshakes, stronger cryptography, and fewer attack surfaces.

Despite the name, when people say “SSL certificate,” they really mean a TLS certificate. The industry never fully let go of the old term.

7. Recap of the Secure Connection Flow

1. DNS Resolution: Domain → IP.
2. TCP Handshake: Connection established.
3. TLS Handshake: Certificate presented, verified, and session keys exchanged.
4. Encrypted HTTP Exchange: Requests and responses transmitted securely.

All of this happens seamlessly, usually within milliseconds, enabling the secure web we take for granted today.

8. Final Thoughts

TLS is the protocol that makes online banking, shopping, messaging, and nearly every form of online interaction safe. It ensures that data cannot be read or altered by intermediaries and that clients can be confident about the identity of the servers they’re communicating with.

Understanding the role of DNS, TCP, TLS handshakes, certificates, and CAs is essential knowledge for any software engineer. Whether you’re building backend services, securing APIs, or just curious about what happens when you type a URL, this flow is the backbone of secure communication on the internet.