What Is HTTPS? SSL/TLS Encryption Explained Simply

From SSL 2.0 to TLS 1.3: A 30-Year History

To understand what HTTPS actually is, it helps to trace how it got here — because the name "SSL" (Secure Sockets Layer) is still used colloquially for what has technically been "TLS" (Transport Layer Security) since 1999.

In the early 1990s, Netscape was building its Navigator browser and needed a way to protect credit card numbers sent to web servers. In 1995 they released SSL 2.0 — the first widely deployed protocol for encrypted web communication. It had critical flaws: no protection against replay attacks, weak cipher negotiation, and padding oracle vulnerabilities.

Netscape fixed those flaws in SSL 3.0 (1996), which became the basis for the IETF standard TLS 1.0 in 1999. The IETF (Internet Engineering Task Force) took ownership, and the protocol was renamed — but "SSL certificate" stuck in common usage, even though the protocol running beneath it has been TLS for 25 years.

Today, only 1.1% of surveyed top websites still support the ancient SSL 2.0 or SSL 3.0, according to SSL Insights (January 2026). All major browsers block connections to TLS 1.0/1.1 servers since 2020–2021.

What HTTPS Actually Guarantees (and What It Doesn't)

HTTPS provides exactly three guarantees. Understanding their precise scope prevents a common security misconception.

• 🔒

  Confidentiality

  Data in transit is encrypted. A network observer (ISP, coffee shop router, hostile middleman) sees only the destination IP and domain name (from SNI) — not the URL path, request headers, or body. Your POST /api/login body with the password is not visible on the wire.

• ✅

  Integrity

  Data cannot be modified in transit without detection. TLS uses authenticated encryption (AES-GCM or ChaCha20-Poly1305) with a MAC for each record. Any bit flip in the ciphertext causes the MAC check to fail and the connection to close. ISPs cannot inject ads into HTTPS responses.

• 🪪

  Authentication

  The server's certificate proves it controls the domain — signed by a CA your browser trusts. You are talking to the real api.stripe.com, not an impostor. This is why getting a certificate requires domain validation (DV), not just installing a file.

What HTTPS does not guarantee: that the server itself is secure, that the application code is safe from SQL injection or XSS, or that the business behind the domain is legitimate. A phishing site at https://paypa1.com has a valid certificate for that domain — it is encrypted phishing. HTTPS is about the channel, not the content.

How the TLS Handshake Works

Every HTTPS connection begins with a TLS handshake — a negotiation where client and server agree on cipher suites, verify identity, and derive encryption keys. TLS 1.3 reduced this to a single round-trip (1-RTT), cutting the connection setup latency roughly in half compared to TLS 1.2.

# TLS 1.3 Handshake (simplified)
# ──────────────────────────────────────────────────────────────

Client → Server:  ClientHello
  - TLS version: 1.3
  - Supported cipher suites: [TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, ...]
  - key_share: client's ephemeral ECDH public key (X25519)
  - server_name: "api.stripe.com"  ← SNI: tells server which cert to serve

Server → Client:  ServerHello + Certificate + Finished (all in one flight)
  - Selected cipher: TLS_AES_256_GCM_SHA384
  - key_share: server's ephemeral ECDH public key
  - Certificate: signed by DigiCert, valid for *.stripe.com, expires 2026-09-01
  - Finished: MAC proving server derived the same session keys

# Both sides now derive identical session keys using:
# client_key_share + server_key_share → shared_secret (ECDH)
# shared_secret → HKDF → client_write_key + server_write_key
# No key ever crosses the wire. This is forward secrecy.

Client → Server:  Finished
  - MAC proving client derived the same keys
  - HTTP request (encrypted) sent immediately — no extra RTT

# Total: 1 round-trip before first byte of application data
# TLS 1.2: 2 round-trips
# TLS 1.3 with 0-RTT resumption: 0 round-trips (for known servers)

The key insight: neither side ever transmits the encryption key. They each independently compute the same session key from their respective public key contributions via ECDH (Elliptic Curve Diffie-Hellman). An eavesdropper who captures the entire handshake cannot derive the key — not even if they later steal the server's private key. This property is called Perfect Forward Secrecy (PFS) and it is mandatory in TLS 1.3. TLS 1.2 only provided it optionally, which is why TLS 1.2 configs needed careful auditing.

TLS Certificates: Chain of Trust Explained

A TLS certificate is a digital document containing a public key and a claim about who controls that key — signed by a Certificate Authority (CA). Browsers trust a certificate because they trust the CA that signed it. This creates a chain of trust.

# Certificate chain for api.example.com
# (inspect with: openssl s_client -connect api.example.com:443 -showcerts)

Root CA Certificate (self-signed, stored in browser/OS trust store)
  └─ Intermediate CA Certificate (signed by Root CA)
      └─ End-Entity Certificate (signed by Intermediate CA)
           domain: api.example.com
           public key: (used for TLS key exchange)
           valid from: 2025-10-01
           valid until: 2025-12-30  ← 90-day certs (Let's Encrypt default)
           issued by: R11 (Let's Encrypt)

# Why 3 layers?
# Root CA keys are kept offline (air-gapped HSMs) — never exposed.
# If an intermediate CA is compromised, it can be revoked without
# rotating the root. Roots are changed via browser/OS updates (years).

The CA/Browser Forum recently passed ballot SC-081, reducing maximum certificate validity to 200 days (effective 2025) and eventually to 47 days by 2027. The rationale: shorter validity windows mean a compromised certificate is revoked faster, and automated renewal (certbot, acme.sh) makes short lifetimes operationally feasible.

Let's Encrypt has transformed certificate issuance. Before 2015, TLS certificates cost $50–$200/year and required manual verification. Let's Encrypt provides certificates for free via the ACME protocol (RFC 8555), automated renewal, and DV (domain validation) — proving you control the domain by serving a challenge file or setting a DNS record. As of January 2026, Let's Encrypt holds 63.9% market share and has issued over 4 billion certificates since launch (Let's Encrypt 2025 Annual Report).

Setting Up HTTPS: Practical Guide

Getting HTTPS set up in 2026 is straightforward. Here are the most common scenarios.

Option 1: certbot + Let's Encrypt (Linux server)

# Install certbot on Ubuntu/Debian
sudo apt install certbot python3-certbot-nginx

# Issue cert and auto-configure nginx
sudo certbot --nginx -d example.com -d www.example.com

# Certbot adds this to nginx config:
# ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Auto-renewal runs via systemd timer (certbot.timer)
# Test renewal: sudo certbot renew --dry-run

# Check renewal status
sudo systemctl status certbot.timer

Option 2: Cloudflare (edge TLS termination)

Cloudflare terminates TLS at their edge, so visitors always get a valid certificate — even if your origin runs plain HTTP. Set SSL/TLS mode to "Full (strict)" to also encrypt origin traffic. This is the easiest path for most sites and is free on Cloudflare's free tier.

Option 3: Node.js/Express with HTTPS

import https from 'https'
import fs from 'fs'
import express from 'express'

const app = express()
app.use(express.json())

// In production, point to Let's Encrypt files
const options = {
  key:  fs.readFileSync('/etc/letsencrypt/live/example.com/privkey.pem'),
  cert: fs.readFileSync('/etc/letsencrypt/live/example.com/fullchain.pem'),

  // Harden TLS configuration
  minVersion: 'TLSv1.2',          // reject TLS 1.0/1.1
  ciphers: [                       // modern cipher suites only
    'TLS_AES_256_GCM_SHA384',
    'TLS_CHACHA20_POLY1305_SHA256',
    'ECDHE-RSA-AES256-GCM-SHA384',
  ].join(':'),
}

https.createServer(options, app).listen(443)

// Redirect HTTP → HTTPS
import http from 'http'
http.createServer((req, res) => {
  res.writeHead(301, { Location: 'https://' + req.headers.host + req.url })
  res.end()
}).listen(80)

HSTS: Hardening HTTPS Against Downgrade Attacks

Even with HTTPS configured, a first-visit attack is possible: an attacker on the network intercepts the initial HTTP request (before the redirect) and serves a fake HTTP site. HTTP Strict Transport Security (HSTS) closes this window.

# nginx: add HSTS header (only serve over HTTPS)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Express.js equivalent
app.use((req, res, next) => {
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload')
  next()
})

# After seeing this header:
# - Browser caches the HSTS policy for 1 year (31536000 seconds)
# - All requests to example.com (and subdomains) are upgraded to HTTPS
#   client-side — no HTTP round-trip at all
# - The "preload" directive submits your domain to browser preload lists:
#   https://hstspreload.org/ — once listed, browsers hard-code the HTTPS
#   requirement even before the first visit

# HSTS preload requirements:
# ✓ Valid HTTPS certificate
# ✓ HTTP redirects to HTTPS
# ✓ All subdomains served over HTTPS
# ✓ max-age >= 31536000
# ✓ includeSubDomains
# ✓ preload directive present

The HSTS preload list is bundled into Chrome, Firefox, Safari, and Edge. Once your domain is on it, there is literally no HTTP connection made — even for first-time visitors. This is why enterprise security teams push for preload enrollment.

Diagnosing TLS Problems: Developer Tools

When HTTPS breaks, the errors are often cryptic. Here is how to diagnose the most common issues:

# 1. Check certificate chain and expiry
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -text | grep -E "Subject|Issuer|Not After"

# 2. Test TLS version and cipher suite support
openssl s_client -connect example.com:443 -tls1_3   # TLS 1.3 only
openssl s_client -connect example.com:443 -tls1_2   # TLS 1.2 only

# 3. Check HSTS header
curl -I https://example.com | grep -i strict

# 4. Verify certificate expiry in days remaining
echo | openssl s_client -connect example.com:443 2>/dev/null   | openssl x509 -noout -dates

# Common errors and causes:
# ERR_CERT_AUTHORITY_INVALID  → self-signed cert or missing intermediate chain
# ERR_CERT_COMMON_NAME_INVALID → cert's domain doesn't match URL (typo or wrong cert)
# ERR_CERT_DATE_INVALID        → certificate expired
# ERR_SSL_VERSION_OR_CIPHER_MISMATCH → server requires TLS 1.3, client is older
# NET::ERR_CERT_REVOKED        → certificate was revoked by CA (rotate immediately)

For a comprehensive TLS audit covering cipher suites, certificate transparency, CAA records, and OCSP stapling, use Qualys SSL Labs (grade A+ is the target) or check our SSL checker guide for the full diagnostic workflow.

HTTP vs HTTPS vs HTTP/2 vs HTTP/3: The Full Picture

A critical point: HTTP/2 is only available over HTTPS in all browsers. The spec allows HTTP/2 without TLS (h2c), but no browser implements it. So enabling HTTPS is a prerequisite for HTTP/2's multiplexing, header compression, and server push — concrete performance wins that make HTTPS sites typically faster than their HTTP/1.1 counterparts despite the TLS overhead.

Per TechnologyChecker.io (2026), 27.8% of the web still runs HTTP/1.x, meaning there is significant performance to be gained simply by migrating to HTTP/2 — which just means enabling HTTPS and ensuring your server supports it (nginx, Apache, Caddy, and all CDNs do by default).

Mixed Content: The Silent HTTPS Killer

Mixed content occurs when an HTTPS page loads subresources (images, scripts, iframes) over HTTP. Browsers block active mixed content (scripts, iframes) and warn on passive mixed content (images). The result is a broken padlock or outright blocking.

<!-- Mixed content — will be blocked in Chrome/Firefox -->
<script src="http://cdn.example.com/library.js"></script>

<!-- Fix: use protocol-relative URL (inherits current page's scheme) -->
<script src="//cdn.example.com/library.js"></script>

<!-- Best: always explicitly use https:// -->
<script src="https://cdn.example.com/library.js"></script>

<!-- Content-Security-Policy: upgrade-insecure-requests
     Tells browser to upgrade all http:// to https:// automatically -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

<!-- Or set it as a response header (preferred over meta tag) -->
Content-Security-Policy: upgrade-insecure-requests

The upgrade-insecure-requests CSP directive is the fastest fix when migrating a legacy site to HTTPS: it automatically rewrites HTTP subresource URLs to HTTPS at the browser level without touching your HTML. You can also check your DNS records to ensure HTTPS redirect is configured at the DNS level.

Frequently Asked Questions

Related Articles