What is SSL/TLS? How HTTPS Encryption and Certificates Work

What is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide encrypted communication between a client (your browser) and a server (a website). When a website uses SSL/TLS, its URL starts with https:// instead of http://.

SSL/TLS provides three critical security guarantees:

SSL/TLS provides:

1. Encryption      → Data is scrambled so eavesdroppers can't read it
                      (even if they intercept the traffic)

2. Authentication  → Proves the server is who it claims to be
                      (you're talking to the real bank, not an impersonator)

3. Integrity       → Detects if data was tampered with in transit
                      (no one modified your bank transfer amount mid-flight)

Without SSL/TLS (HTTP):
  You ──── "password123" ──── Router ──── ISP ──── Server
                 ↑
         Anyone on the network can read this!

With SSL/TLS (HTTPS):
  You ──── "a7f2b9c1e8..." ──── Router ──── ISP ──── Server
                 ↑
         Encrypted — meaningless to interceptors

SSL vs TLS — What's the Difference?

SSL and TLS are often used interchangeably, but they're technically different protocols. TLS is the successor to SSL — it's more secure and is the protocol actually used today. When people say "SSL certificate," they almost always mean a certificate used with TLS.

How HTTPS Works

HTTPS (HyperText Transfer Protocol Secure) is simply HTTP running over a TLS-encrypted connection. The encryption layer sits between HTTP and TCP:

Protocol Stack Comparison:

HTTP (insecure):               HTTPS (secure):
┌──────────────────┐           ┌──────────────────┐
│    HTTP           │           │    HTTP           │
├──────────────────┤           ├──────────────────┤
│                   │           │    TLS/SSL        │  ← encryption layer
├──────────────────┤           ├──────────────────┤
│    TCP            │           │    TCP            │
├──────────────────┤           ├──────────────────┤
│    IP             │           │    IP             │
└──────────────────┘           └──────────────────┘

Port numbers:
  HTTP  → Port 80
  HTTPS → Port 443

What's encrypted:
  ✓ URL path and query string (/account?id=123)
  ✓ HTTP headers (cookies, auth tokens)
  ✓ Request and response body (form data, HTML, JSON)
  ✓ HTTP method (GET, POST, etc.)

What's NOT encrypted:
  ✗ Destination IP address (visible to network)
  ✗ Domain name via SNI* (visible during TLS handshake)
  ✗ Packet size and timing (metadata)

*SNI (Server Name Indication) sends the domain in plaintext
 during the handshake so the server knows which certificate
 to use. Encrypted Client Hello (ECH) is being developed
 to encrypt this too.

The TLS Handshake Explained

Before encrypted communication can begin, the client and server must agree on encryption parameters and exchange keys. This process is called the TLS handshake:

TLS 1.2 Handshake (2 round trips):

Client (Browser)                          Server (Website)
      │                                        │
  1.  │──── ClientHello ──────────────────────→│
      │     • TLS version (1.2)                │
      │     • Supported cipher suites          │
      │     • Client random (28 bytes)         │
      │     • SNI: example.com                 │
      │                                        │
  2.  │←──── ServerHello ─────────────────────│
      │      • Chosen cipher suite             │
      │      • Server random (28 bytes)        │
      │←──── Certificate ─────────────────────│
      │      • Server's SSL certificate        │
      │      • Certificate chain               │
      │←──── ServerHelloDone ─────────────────│
      │                                        │
  3.  │ [Verify certificate]                   │
      │ [Generate pre-master secret]           │
      │──── ClientKeyExchange ────────────────→│
      │     • Pre-master secret (encrypted     │
      │       with server's public key)        │
      │──── ChangeCipherSpec ─────────────────→│
      │──── Finished (encrypted) ─────────────→│
      │                                        │
  4.  │←──── ChangeCipherSpec ────────────────│
      │←──── Finished (encrypted) ────────────│
      │                                        │
      │══════ Encrypted data exchange ════════│


TLS 1.3 Handshake (1 round trip — faster!):

Client                                    Server
      │                                        │
  1.  │──── ClientHello ──────────────────────→│
      │     • TLS 1.3                          │
      │     • Key share (Diffie-Hellman)       │
      │     • Supported groups                 │
      │                                        │
  2.  │←──── ServerHello ─────────────────────│
      │      • Key share                       │
      │←──── EncryptedExtensions ─────────────│
      │←──── Certificate ─────────────────────│
      │←──── CertificateVerify ───────────────│
      │←──── Finished ────────────────────────│
      │                                        │
  3.  │──── Finished ─────────────────────────→│
      │                                        │
      │══════ Encrypted data exchange ════════│

TLS 1.3 improvements:
  • 1 round trip instead of 2 (faster page loads)
  • 0-RTT resumption for repeat connections
  • Removed insecure algorithms (RSA key exchange, RC4, 3DES, etc.)
  • Always uses forward secrecy (Diffie-Hellman)

SSL Certificates — What's Inside

An SSL certificate is a digital document that binds a public key to a domain name. It's issued by a trusted Certificate Authority (CA) and contains:

Certificate contents (X.509 format):

┌────────────────────────────────────────────────┐
│ Subject:                                        │
│   Common Name (CN): www.example.com             │
│   Organization (O):  Example Inc.               │
│   Country (C):       US                         │
│                                                  │
│ Issuer:                                          │
│   Common Name: Let's Encrypt Authority X3       │
│   Organization: Let's Encrypt                   │
│                                                  │
│ Validity:                                        │
│   Not Before: 2026-01-15 00:00:00 UTC           │
│   Not After:  2026-04-15 23:59:59 UTC           │
│                                                  │
│ Public Key:                                      │
│   Algorithm: RSA (2048-bit) or ECDSA (P-256)    │
│   Key: 30 82 01 0a 02 82 01 01 00 bb 47...     │
│                                                  │
│ Subject Alternative Names (SAN):                │
│   DNS: example.com                               │
│   DNS: www.example.com                           │
│   DNS: mail.example.com                          │
│                                                  │
│ Key Usage:                                       │
│   Digital Signature, Key Encipherment            │
│                                                  │
│ Signature:                                       │
│   Algorithm: SHA-256 with RSA                    │
│   Signed by: Let's Encrypt Authority X3         │
│                                                  │
│ Serial Number: 04:AB:7F:C3:...                  │
│ Fingerprint (SHA-256): A1:B2:C3:D4:...          │
└────────────────────────────────────────────────┘

The Subject Alternative Names (SAN) field is particularly important — it lists all the domain names the certificate is valid for. A certificate for example.com won't work for sub.example.com unless the subdomain is listed in the SAN or a wildcard (*.example.com) is used.

Certificate Types: DV, OV, and EV

SSL certificates come in three validation levels, differing in how thoroughly the CA verifies the requester's identity:

There are also wildcard certificates (*.example.com) that cover all subdomains, and multi-domain (SAN) certificates that cover multiple unrelated domains in a single certificate. All types provide the same level of encryption — the difference is only in identity verification.

The Certificate Chain of Trust

Your browser doesn't trust individual SSL certificates directly. Instead, it trusts a small set of root CAs (Certificate Authorities) that come pre-installed with your operating system or browser. These root CAs sign intermediate certificates, which in turn sign your website's certificate:

Certificate Chain of Trust:

┌─────────────────────────────────────┐
│         Root CA Certificate          │  ← Pre-installed in your OS/browser
│  (e.g., "ISRG Root X1")             │     Self-signed, stored in trust store
│  Valid: 2015 – 2035                  │     (~150 root CAs trusted globally)
└──────────────┬──────────────────────┘
               │ signs
               ▼
┌─────────────────────────────────────┐
│     Intermediate CA Certificate      │  ← Signed by root CA
│  (e.g., "R3" by Let's Encrypt)      │     Root CAs stay offline for security
│  Valid: 2020 – 2025                  │     Intermediates do the day-to-day signing
└──────────────┬──────────────────────┘
               │ signs
               ▼
┌─────────────────────────────────────┐
│     Your Website's Certificate       │  ← Signed by intermediate CA
│  (e.g., "www.example.com")          │     This is what your server sends
│  Valid: 2026-01-15 – 2026-04-15     │
└─────────────────────────────────────┘

Browser verification process:
  1. Server sends its certificate + intermediate(s)
  2. Browser checks: Is the certificate expired? → No ✓
  3. Browser checks: Does the domain match? → Yes ✓
  4. Browser follows the chain up to a trusted root
  5. Browser verifies each signature in the chain
  6. If chain is valid → show padlock 🔒
  7. If chain is broken → show warning ⚠️

How to Get an SSL Certificate

Getting an SSL certificate has become remarkably easy and often free:

Getting a certificate with Let's Encrypt (Certbot):

# Install Certbot
$ sudo apt install certbot python3-certbot-nginx

# Obtain and install certificate (Nginx)
$ sudo certbot --nginx -d example.com -d www.example.com

# What happens:
1. Certbot contacts Let's Encrypt
2. Let's Encrypt issues an HTTP challenge
   → Places a file at http://example.com/.well-known/acme-challenge/TOKEN
3. Let's Encrypt verifies the file is accessible
   → Proves you control the domain
4. Certificate is issued and installed automatically
5. Auto-renewal via cron/systemd timer

# Test renewal
$ sudo certbot renew --dry-run

Common SSL/TLS Errors

SSL errors in browsers mean something specific went wrong. Here's what each error means and how to fix it:

SSL/TLS Best Practices

Configuring SSL/TLS correctly is critical. Here are current best practices:

SSL/TLS Configuration Checklist:

Protocol:
  ✓ Enable TLS 1.2 and TLS 1.3
  ✗ Disable SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1

Cipher Suites:
  ✓ Use AEAD ciphers (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305)
  ✗ Disable RC4, 3DES, DES, NULL ciphers
  ✓ Prefer server cipher order (server_prefer_cipher_order on)

Certificates:
  ✓ Use RSA 2048-bit minimum (or ECDSA P-256 for better performance)
  ✓ Include complete certificate chain (don't forget intermediates!)
  ✓ Use SHA-256 or stronger for signature
  ✗ Don't use SHA-1 or MD5 signatures

Headers:
  ✓ Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains
  ✓ Redirect all HTTP → HTTPS (301 redirect)
  ✓ Set Secure flag on all cookies

Monitoring:
  ✓ Monitor certificate expiration dates
  ✓ Set up alerts 30 days before expiry
  ✓ Use Certificate Transparency monitoring
  ✓ Test with SSL Labs (aim for A+ rating)

HSTS — HTTP Strict Transport Security

HSTS tells browsers to always use HTTPS, even if the user types http://. Without HSTS, the initial HTTP request could be intercepted (SSL stripping attack):

Without HSTS:
  User types: example.com
  Browser:    GET http://example.com
  Attacker:   Intercepts HTTP → serves fake page ✗

With HSTS:
  User types: example.com
  Browser:    (remembers HSTS) → GET https://example.com ✓
  Attacker:   Can't intercept — browser went straight to HTTPS

HSTS Header:
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  max-age=31536000     → Remember for 1 year (in seconds)
  includeSubDomains    → Apply to all subdomains too
  preload              → Submit to browser preload list
                         (hard-coded HTTPS in Chrome, Firefox, etc.)

Checking SSL Certificates

Regularly checking your SSL certificate is essential to avoid unexpected expirations or misconfigurations. Here's what to verify:

Checking SSL from the command line:

# View certificate details
$ openssl s_client -connect example.com:443 -servername example.com

# Check expiration date
$ echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

  notBefore=Jan 15 00:00:00 2026 GMT
  notAfter=Apr 15 23:59:59 2026 GMT

# View full certificate info
$ echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text

# Check certificate chain
$ openssl s_client -connect example.com:443 -showcerts