How HTTPS & SSL/TLS Work — Complete Beginner Guide

What is HTTPS?

Every time you visit a website, your browser and the server exchange data. With plain HTTP (HyperText Transfer Protocol), that data travels in cleartext. Anyone sitting between you and the server — a hacker on public Wi-Fi, a compromised router, or a rogue ISP — can read everything: passwords, credit card numbers, personal messages.

HTTPS (HTTP Secure) wraps that same HTTP traffic inside an encrypted tunnel. The data still follows the HTTP protocol, but it is encrypted before leaving your device and decrypted only at the destination.

HTTP vs HTTPS

| Feature | HTTP | HTTPS | |---------|------|-------| | URL prefix | http:// | https:// | | Port | 80 | 443 | | Encryption | None | TLS encryption | | Browser indicator | "Not Secure" warning | Padlock icon | | Data integrity | No guarantee | Tamper-proof | | Authentication | None | Server identity verified |

Why HTTPS Matters

• Security — Encrypts data in transit, preventing eavesdropping and man-in-the-middle attacks.
• Trust — The padlock icon tells visitors their connection is secure. Users abandon sites that show "Not Secure."
• SEO — Google has used HTTPS as a ranking signal since 2014. Sites without it are penalized.
• Compliance — PCI-DSS, HIPAA, and GDPR all require encrypted data transmission.
• Modern features — HTTP/2, service workers, and many browser APIs require HTTPS.

Brief History: SSL to TLS

The encryption protocol behind HTTPS was originally called SSL (Secure Sockets Layer), developed by Netscape in the mid-1990s. After several security flaws were discovered, the protocol was handed to the IETF and renamed TLS (Transport Layer Security). Despite the name change, most people still call it "SSL" out of habit.

SSL vs TLS — What's the Difference?

SSL and TLS are different versions of the same protocol family. SSL is the older, deprecated predecessor. TLS is the modern, actively maintained standard.

Version History

| Protocol | Year | Status | Notes | |----------|------|--------|-------| | SSL 1.0 | 1994 | Never released | Too many security flaws | | SSL 2.0 | 1995 | Deprecated (2011) | Vulnerable to DROWN attack | | SSL 3.0 | 1996 | Deprecated (2015) | Vulnerable to POODLE attack | | TLS 1.0 | 1999 | Deprecated (2020) | Vulnerable to BEAST attack | | TLS 1.1 | 2006 | Deprecated (2020) | No modern cipher support | | TLS 1.2 | 2008 | Widely used | Current baseline standard | | TLS 1.3 | 2018 | Latest & recommended | Faster, more secure |

Why People Still Say "SSL"

The term "SSL" stuck because it was used for over a decade before TLS existed. When someone says "SSL certificate" or "SSL checker," they almost always mean TLS. The certificates themselves are the same — they work with whatever TLS version your server supports.

The simple rule: SSL is dead. TLS is what actually runs. But "SSL" is the common shorthand everyone uses.

How Encryption Works (Simple Explanation)

HTTPS relies on two types of encryption working together. Understanding both is key to understanding the TLS handshake.

Symmetric Encryption

One key encrypts the data. The same key decrypts it.

Plaintext: "Hello"
     |
     v  [Encrypt with Key-A]
Ciphertext: "x8f2k..."
     |
     v  [Decrypt with Key-A]
Plaintext: "Hello"

Algorithm: AES (Advanced Encryption Standard) — AES-128 or AES-256.

Pros: Extremely fast. Can encrypt gigabytes of data per second.

Cons: Both sides need the same key. How do you share the key securely over an insecure network? This is the key distribution problem.

Asymmetric Encryption

Two mathematically linked keys: a public key and a private key. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

Plaintext: "Hello"
     |
     v  [Encrypt with Public Key]
Ciphertext: "m9z1q..."
     |
     v  [Decrypt with Private Key]
Plaintext: "Hello"

Algorithms: RSA (2048-bit or 4096-bit), ECDSA (Elliptic Curve).

Pros: Solves the key distribution problem. You can share the public key with everyone.

Cons: 100-1000x slower than symmetric encryption. Not practical for bulk data.

How HTTPS Uses Both

HTTPS combines the strengths of both approaches:

1. Asymmetric encryption is used during the handshake to securely exchange a shared secret.
2. That shared secret is used to derive symmetric session keys.
3. Symmetric encryption handles the actual data transfer — fast and efficient.

The Locked Box Analogy

Imagine Alice wants to send Bob a secret message:

1. Bob sends Alice an open padlock (public key) but keeps the key (private key).
2. Alice puts her message in a box and locks it with Bob's padlock.
3. Only Bob can open it because only he has the key.
4. Inside the box, Alice included a new shared key they can both use going forward — this is faster than sending padlocks back and forth for every message.

That is essentially what HTTPS does.

The TLS Handshake — Step by Step

Before any encrypted data flows, the browser and server must agree on how to encrypt. This negotiation is called the TLS handshake. Here is how TLS 1.2 works:

TLS 1.2 Handshake Flow

Client (Browser)                          Server
      |                                      |
      |  1. ClientHello ----------------->   |
      |     - TLS version (1.2)              |
      |     - Random number (client)         |
      |     - Supported cipher suites        |
      |     - Supported compression          |
      |                                      |
      |  <-------------- 2. ServerHello      |
      |     - Chosen cipher suite            |
      |     - Random number (server)         |
      |     - Session ID                     |
      |                                      |
      |  <------------- 3. Certificate       |
      |     - Server's SSL certificate       |
      |     - Certificate chain              |
      |                                      |
      |  <--------- 4. ServerKeyExchange     |
      |     - ECDHE parameters (if used)     |
      |                                      |
      |  <---------- 5. ServerHelloDone      |
      |                                      |
      |  6. ClientKeyExchange ----------->   |
      |     - Pre-master secret              |
      |       (encrypted with server's       |
      |        public key)                   |
      |                                      |
      |  [Both sides compute session keys    |
      |   from: pre-master secret +          |
      |   client random + server random]     |
      |                                      |
      |  7. ChangeCipherSpec ------------>   |
      |  8. Finished (encrypted) -------->   |
      |                                      |
      |  <---------- 9. ChangeCipherSpec     |
      |  <----------- 10. Finished (enc.)   |
      |                                      |
      |  === Encrypted Data Flows =========  |

Step-by-Step Breakdown

Step 1: Client Hello — Your browser sends a greeting that says: "I support TLS 1.2, here are the cipher suites I know, and here's a random number."

Step 2: Server Hello — The server picks the strongest cipher suite both sides support, generates its own random number, and sends both back.

Step 3: Certificate — The server sends its SSL/TLS certificate, which contains the server's public key and is signed by a trusted Certificate Authority.

Step 4: Server Key Exchange — If using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), the server sends additional parameters needed for the key exchange.

Step 5: Server Hello Done — The server signals it has finished its part of the negotiation.

Step 6: Client Key Exchange — The browser generates a pre-master secret, encrypts it with the server's public key, and sends it. Only the server can decrypt this because only it holds the private key.

Steps 7-10: Finished — Both sides use the pre-master secret plus the two random numbers to independently compute the same session keys. They exchange "Finished" messages encrypted with these new keys to verify everything worked.

From this point on, all data is encrypted with the symmetric session keys.

TLS 1.3 — Faster and More Secure

TLS 1.3, finalized in 2018, is a major improvement:

| Feature | TLS 1.2 | TLS 1.3 | |---------|---------|---------| | Handshake round trips | 2 RTT | 1 RTT | | 0-RTT resumption | No | Yes | | Cipher suites | 37+ (many weak) | 5 strong suites only | | Key exchange | RSA or ECDHE | ECDHE only (forward secrecy mandatory) | | Removed features | — | RSA key exchange, RC4, DES, SHA-1, compression |

1-RTT Handshake: TLS 1.3 combines several steps. The client sends its key share in the very first message, so the server can compute session keys immediately. The handshake completes in one round trip instead of two.

0-RTT Resumption: If the client has connected to the server before, it can send encrypted application data in the very first message — zero round trips for the handshake. This is a trade-off: 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (like GET).

Forward Secrecy: TLS 1.3 requires ephemeral key exchange (ECDHE). Even if the server's private key is compromised in the future, past sessions cannot be decrypted. TLS 1.2 allowed RSA key exchange, which did not provide this guarantee.

SSL/TLS Certificates

A certificate is the identity card of a server. It proves the server is who it claims to be.

What a Certificate Contains

| Field | Example | |-------|---------| | Subject (domain) | www.example.com | | Issuer | DigiCert Global G2 | | Valid from | 2026-01-01 | | Valid until | 2027-01-01 | | Public key | RSA 2048-bit or ECDSA P-256 | | Signature algorithm | SHA-256 with RSA | | Serial number | 0A:1B:2C:3D:... | | Subject Alternative Names (SAN) | example.com, www.example.com |

Certificate Types

| Type | Validation | Time to Issue | Indicator | Cost | |------|-----------|---------------|-----------|------| | DV (Domain Validation) | Prove domain ownership | Minutes | Padlock | Free — $50/yr | | OV (Organization Validation) | Verify business identity | 1-3 days | Padlock + org name in cert details | $50 — $200/yr | | EV (Extended Validation) | Thorough business vetting | 1-2 weeks | Padlock + org name in cert details | $100 — $500/yr |

DV is sufficient for most websites. OV and EV provide additional trust signals for businesses handling sensitive data.

Certificate Authorities (CAs)

A Certificate Authority is a trusted third party that issues certificates. Your browser and operating system ship with a list of trusted root CAs.

Major CAs include:

• Let's Encrypt — Free, automated DV certificates. Powers over 300 million websites.
• DigiCert — Enterprise-grade. Acquired Symantec's CA business.
• Sectigo (formerly Comodo) — Wide range of certificate products.
• GlobalSign — Popular for enterprise and IoT.
• Google Trust Services — Google's own CA.

The Certificate Chain of Trust

Browsers do not trust server certificates directly. They follow a chain:

Root CA Certificate          (pre-installed in your OS/browser)
     |
     v  [signs]
Intermediate CA Certificate  (included in server's response)
     |
     v  [signs]
Server Certificate           (your website's cert)

Your browser walks up the chain: "Is the server cert signed by a trusted intermediate? Is that intermediate signed by a trusted root?" If the chain is valid and the root CA is in the browser's trust store, the certificate is accepted.

Let's Encrypt and Free Certificates

Let's Encrypt revolutionized HTTPS adoption by providing free, automated DV certificates. Using the ACME protocol, tools like Certbot can:

1. Prove you control the domain (via HTTP challenge or DNS challenge).
2. Issue a certificate in seconds.
3. Auto-renew every 60-90 days.

Wildcard Certificates

A wildcard certificate covers a domain and all its single-level subdomains:

*.example.com covers:
  - www.example.com
  - mail.example.com
  - api.example.com

Does NOT cover:
  - example.com        (need to add as SAN)
  - sub.api.example.com (two levels deep)

Wildcard certificates require DNS-based validation with Let's Encrypt.

Cipher Suites Explained

A cipher suite is a set of algorithms that defines exactly how the TLS connection will be secured. When your browser connects to a server, they negotiate which cipher suite to use.

Breaking Down a Cipher Suite

Take this example:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

| Component | Value | Purpose | |-----------|-------|---------| | Protocol | TLS | Transport Layer Security | | Key Exchange | ECDHE | Elliptic Curve Diffie-Hellman Ephemeral — how keys are exchanged | | Authentication | RSA | How the server proves its identity | | Encryption | AES_256_GCM | AES with 256-bit key in Galois/Counter Mode — bulk encryption | | Hash / MAC | SHA384 | Integrity verification |

TLS 1.3 Cipher Suites

TLS 1.3 simplified cipher suites by separating the key exchange from the cipher. Only five suites are defined:

TLS_AES_256_GCM_SHA384        (recommended)
TLS_AES_128_GCM_SHA256        (recommended)
TLS_CHACHA20_POLY1305_SHA256  (recommended — fast on mobile)
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

Key exchange is always ECDHE (or DHE), and authentication is determined by the certificate type. This eliminates the risk of accidentally configuring a weak cipher suite.

Recommended Configuration for 2026

For Nginx, a strong TLS configuration looks like:

How to Check Which Cipher Your Site Uses

Open your browser's developer tools and navigate to the Security tab. Or use the command line:

Common SSL/TLS Issues

Certificate Expired

Symptom: Browser shows "Your connection is not private" with error code NET::ERR_CERT_DATE_INVALID.

Fix: Renew the certificate. If using Let's Encrypt, check that the auto-renewal cron job or systemd timer is working:

Mixed Content

Symptom: Padlock shows a warning. Console logs: "Mixed Content: The page was loaded over HTTPS, but requested an insecure resource."

Fix: Ensure all resources (images, scripts, stylesheets, fonts, API calls) use https:// or protocol-relative URLs. Search your codebase:

Certificate Name Mismatch

Symptom: NET::ERR_CERT_COMMON_NAME_INVALID — the certificate was issued for a different domain.

Fix: Ensure the certificate's Subject Alternative Names (SAN) include all domains you serve. If you serve example.com and www.example.com, both must be in the certificate.

Self-Signed Certificate Warnings

Symptom: NET::ERR_CERT_AUTHORITY_INVALID — the certificate was not issued by a trusted CA.

Fix: Use a certificate from a trusted CA. Self-signed certificates are fine for local development but must never be used in production. Use Let's Encrypt for free trusted certificates.

Weak Cipher Suites

Symptom: Security scanners flag weak ciphers (RC4, DES, 3DES, export ciphers).

Fix: Update your server configuration to only allow strong ciphers. Disable TLS 1.0 and 1.1. Use the Mozilla SSL Configuration Generator to create a secure configuration for your server software.

How to Check Your SSL Certificate

Browser Method

1. Click the padlock icon in the address bar.
2. Click "Connection is secure" (or similar).
3. Click "Certificate" to view details.
4. Check: issuer, expiry date, domain names covered.

Command Line with OpenSSL

What to Look For

| Check | What It Means | |-------|--------------| | Valid dates | Certificate is not expired and not yet valid | | Correct domain | Certificate covers the domain you are visiting | | Trusted issuer | Issued by a recognized CA, not self-signed | | Strong signature | SHA-256 or better (not SHA-1) | | Key size | RSA 2048+ or ECDSA P-256+ | | Chain complete | Intermediate certificates are served correctly |

Best Practices

Always Use TLS 1.2 or 1.3

Disable TLS 1.0 and 1.1 on your server. They have known vulnerabilities and are no longer supported by modern browsers.

Enable HSTS (HTTP Strict Transport Security)

HSTS tells browsers to always use HTTPS for your domain, even if the user types http://. This prevents SSL stripping attacks.

max-age=63072000 means the browser will remember to use HTTPS for 2 years. The preload directive lets you submit your domain to the HSTS preload list, which is hardcoded into browsers.

Use Strong Cipher Suites

Remove support for weak ciphers. Use the Mozilla SSL Configuration Generator to create a configuration tailored to your server software and desired compatibility level.

Auto-Renew Certificates

Certificates expire. Automated renewal eliminates the risk of downtime from an expired certificate.

Redirect All HTTP to HTTPS

Ensure every HTTP request is permanently redirected to HTTPS:

Enable OCSP Stapling

Normally, browsers check if a certificate has been revoked by contacting the CA's OCSP server. This is slow and leaks browsing data. OCSP stapling lets your server fetch the OCSP response and include it in the TLS handshake — faster and more private.

Quick Reference: TLS Checklist

Use this checklist to verify your HTTPS setup:

• [ ] TLS 1.2 or 1.3 only (no SSLv3, TLS 1.0, TLS 1.1)
• [ ] Strong cipher suites (AES-GCM, ChaCha20-Poly1305)
• [ ] Valid certificate from a trusted CA
• [ ] Certificate covers all domains (including www)
• [ ] Certificate chain is complete (intermediates served)
• [ ] HSTS header enabled with long max-age
• [ ] HTTP redirects to HTTPS (301)
• [ ] No mixed content
• [ ] OCSP stapling enabled
• [ ] Auto-renewal configured and tested

Verify Your Site's Security

Understanding how HTTPS and TLS work is the first step. The next step is making sure your own site is properly configured.

Check your website's SSL certificate with our free SSL Checker Tool — verify certificate validity, expiration, and security configuration instantly.

Summary

HTTPS protects data in transit using TLS encryption. The protocol combines asymmetric encryption (for secure key exchange) with symmetric encryption (for fast data transfer). The TLS handshake establishes trust through certificates signed by Certificate Authorities, negotiates cipher suites, and derives session keys — all before a single byte of application data is sent.

TLS 1.3 made this process faster (one round trip instead of two) and more secure (removing weak algorithms entirely). With free certificates from Let's Encrypt and modern server configurations, there is no reason not to use HTTPS on every website.

The core concepts to remember:

• HTTPS = HTTP + TLS — encrypted transport for web traffic.
• Asymmetric encryption solves the key-sharing problem; symmetric encryption handles the bulk data.
• The TLS handshake negotiates the connection, verifies identity, and establishes session keys.
• Certificates prove server identity and are signed by trusted CAs.
• TLS 1.3 is the current standard — faster, simpler, and more secure.