SSL/TLS Explained: How HTTPS Actually Works

Every time you load a page over HTTPS, your browser and the server perform a cryptographic handshake in milliseconds. According to W3Techs, 85.4% of all websites now default to HTTPS as of early 2026. Yet most developers can’t explain what actually happens during that handshake.

This guide walks through the TLS handshake step by step, explains certificate chains from root to leaf, and covers the real-world errors you’ll hit in production. No hand-waving. No “it just encrypts things.” Actual protocol mechanics.

network security tools

Check Your SSL Configuration

Test any domain’s SSL certificate, chain completeness, and protocol support instantly.

What Is the Difference Between SSL and TLS?

SSL and TLS are different versions of the same protocol, but the industry still says “SSL” out of habit. Netscape released SSL 2.0 in 1995 and SSL 3.0 in 1996. The IETF took over in 1999, renamed it TLS 1.0, and has published four TLS versions since (RFC 8446, 2018).

Citation capsule: SSL (Secure Sockets Layer) was deprecated after version 3.0 due to the POODLE vulnerability disclosed in 2014. TLS (Transport Layer Security) replaced it, with TLS 1.3 published as RFC 8446 by the IETF in 2018. When someone says “SSL certificate,” they mean a TLS certificate.

Here’s the actual timeline:

• SSL 2.0 (1995) - First public release by Netscape. Broken by design, never use it.
• SSL 3.0 (1996) - Major rewrite. Killed by the POODLE attack in 2014.
• TLS 1.0 (1999) - SSL 3.0 with an IETF stamp. Deprecated in 2021.
• TLS 1.1 (2006) - Minor fixes. Also deprecated in 2021.
• TLS 1.2 (2008) - Still widely used. Supports modern cipher suites.
• TLS 1.3 (2018) - Current standard. Faster, simpler, more secure.

So why does everyone still say “SSL”? Branding inertia. Certificate authorities still sell “SSL certificates.” The openssl command-line tool still has that name. But every “SSL certificate” sold today actually uses TLS. The terms are interchangeable in casual conversation, but technically, SSL is dead.

check protocol support

How Does the TLS 1.3 Handshake Work?

TLS 1.3 completes a full handshake in just one round trip (1-RTT), compared to two round trips in TLS 1.2. According to Cloudflare’s performance analysis, this single change reduced connection latency by 100-200ms on average for users worldwide. Here’s what happens step by step, with the actual messages exchanged:

Client                                              Server
  |                                                    |
  |  1. ClientHello                                    |
  |    - TLS version (1.3)                             |
  |    - Random bytes (32 bytes)                       |
  |    - Supported cipher suites                       |
  |    - Key share (client's ECDHE public key)         |
  |  ------------------------------------------------> |
  |                                                    |
  |                          2. ServerHello            |
  |                            - Chosen cipher suite   |
  |                            - Key share (server's   |
  |                              ECDHE public key)     |
  |                          3. EncryptedExtensions    |
  |                          4. Certificate            |
  |                          5. CertificateVerify      |
  |                          6. Finished               |
  |  <------------------------------------------------ |
  |                                                    |
  |  ** Both sides now derive the session key **       |
  |  ** using the exchanged key shares **              |
  |                                                    |
  |  7. Finished                                       |
  |  ------------------------------------------------> |
  |                                                    |
  |  ========= Encrypted application data =========   |
  |  <----------------------------------------------> |

Step 1: ClientHello

The browser sends its opening message. This includes a list of supported cipher suites, a 32-byte random value, and, crucially, the client’s key share. That key share is the big TLS 1.3 change. In TLS 1.2, the client waited to learn the server’s preferences before generating key material. In 1.3, it guesses which key exchange the server will pick and sends its public key upfront.

Step 2-6: Server responds with everything at once

The server picks a cipher suite, sends its own key share, and then immediately sends the certificate, proof of ownership (CertificateVerify), and its Finished message. All of this happens in a single flight. In TLS 1.2, this took two separate exchanges.

Both sides now have each other’s ECDHE public keys. They independently compute the same shared secret using elliptic curve Diffie-Hellman. Nobody watching the wire can derive this secret, even if they recorded every byte.

Step 7: Client confirms

The client sends its own Finished message. From this point, all data is encrypted with the derived session keys. The handshake took one round trip. Done.

Citation capsule: TLS 1.3 reduced the handshake from two round trips to one by having the client send its key share in the initial ClientHello message. Cloudflare reported that this cut connection setup latency by 100-200ms on average across their global network, directly improving time-to-first-byte for 30+ million websites.

What about 0-RTT resumption?

TLS 1.3 also supports 0-RTT mode for returning visitors. If the client has a pre-shared key (PSK) from a previous session, it can send encrypted application data in the very first message. Zero round trips before data starts flowing.

But 0-RTT comes with a catch: it’s vulnerable to replay attacks. An attacker who captures a 0-RTT ClientHello can replay it. For safe use, servers should only accept 0-RTT for idempotent requests (like GET). The IETF explicitly warns about this in RFC 8446, Section 8.

understand DNS resolution

How Do TLS Versions Compare?

According to Qualys SSL Labs monthly scans, 99.6% of surveyed sites support TLS 1.2, while TLS 1.3 adoption reached 72.3% by early 2026. Here’s how the versions stack up on the features that matter.

The biggest security improvement in TLS 1.3 isn’t speed. It’s the removal of RSA key exchange. In TLS 1.2, servers could use static RSA, where the same private key decrypts every session. If that key ever leaked, an attacker could decrypt all past recorded traffic. TLS 1.3 requires ephemeral Diffie-Hellman, so every session gets unique keys. Even a compromised server key can’t decrypt old sessions. Why does this matter practically? Because intelligence agencies and attackers do record encrypted traffic. It’s called “store now, decrypt later.” Forward secrecy makes this strategy useless, since there’s no single key to steal.

How Do Certificate Chains Work?

Certificate chains form a trust hierarchy from your server’s certificate up to a root CA that browsers trust by default. According to Qualys SSL Labs 2025 data, incomplete certificate chains account for roughly 60% of all SSL configuration errors they detect across scanned servers.

Citation capsule: A certificate chain consists of three layers: the leaf (your domain), an intermediate CA, and a root CA. Browsers ship with a pre-installed set of roughly 150 root CA certificates (Mozilla NSS, 2025). If any link in the chain is missing or expired, the connection fails.

The three layers

  ┌─────────────────────────────────┐
  │  Root CA Certificate            │  Pre-installed in browsers/OS
  │  (e.g., ISRG Root X1)          │  Self-signed, ~150 trusted roots
  └──────────────┬──────────────────┘
                 │ signs
  ┌──────────────▼──────────────────┐
  │  Intermediate CA Certificate    │  Issued by the root CA
  │  (e.g., R3, E1)                │  Your server MUST send this
  └──────────────┬──────────────────┘
                 │ signs
  ┌──────────────▼──────────────────┐
  │  Leaf Certificate               │  Your domain's certificate
  │  (e.g., kordu.tools)           │  Contains your public key
  └─────────────────────────────────┘

Why intermediates exist

Root CAs are too valuable to use directly. Their private keys are stored in air-gapped hardware security modules (HSMs) in secure facilities. If a root key were compromised, every certificate it ever signed would need to be revoked, affecting millions of sites.

Intermediates act as a buffer. Root CAs sign a handful of intermediate certificates, and those intermediates sign the millions of leaf certificates. If an intermediate is compromised, only that intermediate gets revoked. The root stays safe.

The most common chain error

Your server must send the intermediate certificate along with the leaf. Browsers don’t have intermediates pre-installed. They only have roots. If you only send your leaf certificate, the browser can’t build a path to a trusted root.

Some browsers, notably Chrome, try to fetch missing intermediates via the Authority Information Access (AIA) extension. Firefox doesn’t. So a misconfigured chain might work in Chrome but fail in Firefox. This inconsistency makes debugging painful.

Here’s how to check your chain with openssl:

# View the full certificate chain from a server
openssl s_client -connect kordu.tools:443 -showcerts

# Verify the chain explicitly
openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem

test your certificate chain

What Are the Different Certificate Types?

Three validation levels exist for SSL/TLS certificates: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). According to Netcraft’s 2025 Web Server Survey, DV certificates now represent 94% of all issued certificates, driven by Let’s Encrypt’s dominance.

Citation capsule: Domain Validation (DV) certificates account for 94% of all issued TLS certificates as of 2025 (Netcraft Web Server Survey). Since major browsers removed the EV green address bar in 2019, there’s no visible difference between DV and EV certificates in the browser UI, making DV the practical default. Here’s the blunt truth: for most websites, DV certificates are all you need. Ever since Chrome, Firefox, and Safari removed the green EV address bar in 2019, there’s no user-visible difference between a free Let’s Encrypt cert and a $500 EV cert. Users don’t check certificate details. They check for the padlock.

OV and EV still have legitimate uses. Financial institutions, government sites, and organizations with strict compliance requirements (PCI-DSS, SOC 2) may need them for audit purposes, not browser UI.

How Does HTTPS Encryption Actually Work?

HTTPS uses two types of encryption together: asymmetric (public-key) cryptography for the handshake, and symmetric encryption for the data transfer. According to Google’s transparency report, 95% of Chrome traffic on all platforms now travels over HTTPS as of 2026.

Asymmetric encryption (the handshake)

Asymmetric encryption uses a key pair: one public, one private. Anything encrypted with the public key can only be decrypted with the private key. This solves the bootstrapping problem. How do two strangers establish a shared secret over a public network?

In TLS 1.3, the answer is Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Both sides generate temporary key pairs, exchange public keys, and independently compute the same shared secret. The math works so that knowing both public keys isn’t enough to derive the secret. You need at least one private key.

Symmetric encryption (the data)

Once both sides share a secret, they derive symmetric session keys. Symmetric encryption (AES-256-GCM or ChaCha20-Poly1305 in TLS 1.3) is fast, roughly 1000x faster than asymmetric operations according to benchmarks from the OpenSSL project.

Every byte of HTTP data, headers, cookies, request bodies, response bodies, is encrypted with these session keys. An eavesdropper sees only opaque ciphertext.

Why both?

Asymmetric is slow but solves key distribution. Symmetric is fast but requires a shared secret. TLS uses asymmetric to establish the secret, then switches to symmetric for bulk data. It’s the best of both worlds.

HTTP protocol fundamentals

What Are Common SSL Errors and How Do You Fix Them?

SSL errors account for roughly 5% of all website accessibility issues according to HTTP Archive crawl data from 2025. Most are configuration mistakes, not actual security incidents. Here are the errors you’ll encounter most often.

ERR_CERT_AUTHORITY_INVALID

Cause: The browser can’t build a chain to a trusted root. Usually means your server isn’t sending the intermediate certificate.

Fix: Configure your web server to send the full chain. In nginx:

# Wrong - leaf only
ssl_certificate /etc/ssl/example.com.crt;

# Right - leaf + intermediate concatenated
ssl_certificate /etc/ssl/example.com.fullchain.crt;

ERR_CERT_DATE_INVALID

Cause: The certificate has expired or isn’t valid yet.

Fix: Renew the certificate. If you use Let’s Encrypt, check that your auto-renewal cron job or certbot timer is running:

# Check certbot timer status
sudo systemctl status certbot.timer

# Force a renewal test
sudo certbot renew --dry-run

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Cause: The server and browser can’t agree on a TLS version or cipher suite. Often happens when a server only supports deprecated protocols.

Fix: Update your TLS configuration. A solid modern config:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

NET_ERR_CERT_COMMON_NAME_INVALID

Cause: The domain you’re visiting doesn’t match the domain(s) listed in the certificate’s Subject Alternative Name (SAN) field.

Fix: Reissue the certificate with the correct domain names. Remember that example.com and www.example.com are different SANs. Most CAs include both automatically, but check.

Mixed content warnings

Cause: An HTTPS page loads resources (images, scripts, stylesheets) over plain HTTP.

Fix: Update all resource URLs to HTTPS, or use protocol-relative URLs. Better yet, set a Content-Security-Policy header:

Content-Security-Policy: upgrade-insecure-requests;

How Does Let’s Encrypt Work?

Let’s Encrypt issues over 5 million certificates per day according to the Internet Security Research Group (ISRG), the nonprofit behind it. It provides free DV certificates using the ACME protocol, which automates the entire issuance and renewal process.

Citation capsule: Let’s Encrypt, operated by ISRG, issues over 5 million certificates daily and has issued more than 4 billion certificates since launch in 2015 (ISRG, 2025). The ACME protocol (RFC 8555) automates domain validation, certificate issuance, and renewal without human intervention.

The ACME protocol in 4 steps

1. Account registration. Your ACME client (certbot, acme.sh, Caddy) registers with Let’s Encrypt and generates an account key pair.

2. Domain validation. You prove you control the domain. Three challenge types exist:

   • HTTP-01: Place a file at http://yourdomain/.well-known/acme-challenge/{token}. Simplest, works for most setups.
   • DNS-01: Create a _acme-challenge TXT record. Required for wildcard certificates.
   • TLS-ALPN-01: Respond on port 443 with a special self-signed cert. Useful when port 80 is blocked.

3. Certificate issuance. After validation passes, your client submits a Certificate Signing Request (CSR). Let’s Encrypt signs it and returns the certificate.

4. Auto-renewal. Certificates last 90 days. Your client automatically renews them before expiry, typically at the 60-day mark.

Quick setup with certbot

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

# Obtain and install a certificate for nginx
sudo certbot --nginx -d example.com -d www.example.com

# Verify auto-renewal works
sudo certbot renew --dry-run

The 90-day certificate lifetime isn’t a limitation. It’s a feature. Short-lived certificates reduce the blast radius of key compromise. If a key leaks, the window of vulnerability is at most 90 days, often less. Traditional 1-year certificates leave you exposed much longer. The automation that 90-day lifetimes force is itself a security improvement, because manual renewal is how certificates expire unexpectedly.

DNS validation requires correct records

How Should You Test Your SSL Setup?

Running a proper SSL test catches misconfigured chains, weak ciphers, and protocol issues before users hit them. Qualys SSL Labs grades roughly 150,000 domains per month and remains the industry standard for SSL assessments.

Command-line testing with openssl

# Test connection and view certificate details
openssl s_client -connect example.com:443 -servername example.com

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

# List supported cipher suites
openssl s_client -connect example.com:443 -cipher 'ALL' 2>&1 | \
  grep -E "Cipher|Protocol"

# Test specific TLS version support
openssl s_client -connect example.com:443 -tls1_3
openssl s_client -connect example.com:443 -tls1_2

What to check

• Certificate chain completeness. All intermediates present.
• Protocol versions. TLS 1.2 and 1.3 only. Nothing older.
• Cipher suite strength. No CBC-mode ciphers, no RC4, no 3DES.
• Forward secrecy. All cipher suites should use ECDHE.
• HSTS header. Strict-Transport-Security with a long max-age.
• Certificate expiry. At least 15 days remaining for buffer.
• OCSP stapling. Faster revocation checking, better privacy.

run an instant SSL test

Frequently Asked Questions

Is TLS 1.2 still secure?

Yes. TLS 1.2 remains secure when configured with modern cipher suites (ECDHE key exchange, AES-GCM or ChaCha20). The IETF has not deprecated TLS 1.2, and it’s still required for broad compatibility. TLS 1.3 is preferred for performance and its smaller attack surface, but 1.2 isn’t going anywhere soon.

Do I need a paid SSL certificate?

For most websites, no. Let’s Encrypt’s free DV certificates provide the same encryption strength as paid certificates. According to ISRG statistics, Let’s Encrypt secures over 360 million websites. Paid certificates only add value when you need OV/EV validation for compliance, or when a vendor requires a specific CA.

Does HTTPS slow down my website?

Modern TLS adds negligible latency. TLS 1.3’s 1-RTT handshake adds roughly 50-100ms on the first connection, and 0-RTT resumption eliminates even that on repeat visits. HTTP/2, which requires HTTPS in all major browsers, actually makes sites faster through multiplexing and header compression. HTTPS is a net performance win.

What happens when a certificate expires?

Browsers display a full-page security warning that blocks access by default. Users can click through the warning in most browsers, but few do. According to Google Chrome telemetry, expired certificates cause immediate bounce rates above 90%. Search engines may also deindex pages returning certificate errors.

How do wildcard certificates work?

A wildcard certificate covers a domain and all single-level subdomains. For example, *.example.com covers www.example.com, api.example.com, and blog.example.com, but not example.com itself or sub.blog.example.com. You need DNS-01 validation to get a wildcard from Let’s Encrypt. Include the bare domain as a separate SAN alongside the wildcard.

Wrapping Up

HTTPS isn’t optional anymore. It’s a baseline expectation from browsers, search engines, and users. The good news: the protocol itself is well-designed, free certificates are available from Let’s Encrypt, and TLS 1.3 made the whole process faster.

The most important things to get right: send your full certificate chain (leaf plus intermediates), disable anything older than TLS 1.2, enable HSTS, and automate your renewals. These four steps prevent the vast majority of SSL issues in production.

If you haven’t audited your setup recently, test it now. Tools like our SSL checker and Qualys SSL Labs give you an instant view of where you stand.

test your SSL configuration related guide on HTTP status codes