HTTPS and SSL/TLS Certificates Demystified

That padlock icon in your browser's address bar — that's HTTPS. Nearly every site uses it now, so it feels unremarkable. But surprisingly few people understand what's actually happening behind it.

The Problem with HTTP

HTTP sends data in plaintext. When you type a password into a login form and hit submit, that password travels across the network as raw text.

Why is this bad? Anyone along the network path can intercept the packets. On public Wi-Fi — a coffee shop, airport, hotel — someone on the same network with a packet capture tool can read all HTTP traffic. Usernames, passwords, credit card numbers. All of it, in the clear.

HTTPS fixes this by encrypting the data in transit. Even if someone captures the packets, they can't read the contents.

SSL, TLS — Why Two Names?

This causes a lot of confusion. Here's the short version.

SSL (Secure Sockets Layer) was created by Netscape in the 1990s. It went through version 3.0 before security flaws led to its retirement.

TLS (Transport Layer Security) is SSL's successor. Built on SSL 3.0, it's currently at version 1.3. As of 2026, TLS 1.2 and TLS 1.3 are the versions in active use.

Technically, "TLS certificate" is the correct term. But the industry still says "SSL certificate" out of habit. "SSL/TLS certificate" covers all bases. The key takeaway: even when someone says SSL, TLS is what's actually running.

How an HTTPS Connection Is Established

When your browser hits https://example.com, a process called the TLS handshake happens behind the scenes.

Step 1 — Client Hello

The browser connects to the server, sending its supported TLS versions and cipher suites (encryption methods).

Step 2 — Server Hello

The server picks a TLS version and cipher suite, then sends its certificate. The certificate contains the server's public key and a signature from a Certificate Authority (CA) confirming "this server really is example.com."

Step 3 — Certificate Verification

The browser checks whether the certificate was issued by a trusted CA, whether it's expired, and whether the domain matches. If anything fails, you get the "Your connection is not private" warning.

Step 4 — Key Exchange

Once verified, both sides derive a symmetric key for this session. TLS 1.3 uses key exchange algorithms like ECDHE for this.

Step 5 — Encrypted Communication

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

The whole thing happens in milliseconds. TLS 1.3 completes the handshake in a single round trip (1-RTT). For servers you've connected to before, 0-RTT lets data flow immediately.

Who Issues Certificates?

Certificates come from Certificate Authorities (CAs). A CA vouches that the certificate holder genuinely owns the domain. Browsers ship with a list of trusted CAs, and only certificates signed by those CAs are accepted as valid.

Three types of certificates:

• DV (Domain Validation) — Verifies domain ownership only. Fastest and simplest. Sufficient for personal sites and blogs
• OV (Organization Validation) — Verifies domain + organization identity. Common for business websites
• EV (Extended Validation) — Rigorous verification process. Used to turn the address bar green, but modern browsers show the same padlock as DV. Its practical value has diminished

Let's Encrypt Changed Everything

Before 2015, SSL certificates cost money. Anywhere from $10 to hundreds of dollars per year. For a personal blog, that was hard to justify.

Let's Encrypt changed the game. It's a nonprofit CA that issues free DV certificates with automated provisioning. Tools like Certbot handle issuance, installation, and renewal. Certificates expire every 90 days, but with automation, you never think about it.

Hosting platforms like Vercel, Netlify, and Cloudflare provide HTTPS out of the box. Connect a domain and the certificate is issued and renewed automatically. In 2026, there's almost no scenario where you need to buy a certificate separately.

What Happens Without HTTPS

Beyond the security risk, there are tangible consequences.

Browser warnings — Chrome labels HTTP sites as "Not Secure" in the address bar. Users notice, and trust drops immediately.

SEO penalty — Google uses HTTPS as a ranking signal. All else equal, HTTPS sites rank higher than HTTP ones.

Blocked browser APIs — Service Workers, geolocation, camera/microphone access — these APIs require HTTPS. They're completely blocked on HTTP.

No HTTP/2 or HTTP/3 — Modern HTTP protocols are designed with HTTPS as a requirement. Performance optimization depends on HTTPS.

What Developers Should Know

HTTPS setup is mostly handled by hosting providers these days, but there are still things to get right during development.

Prevent mixed content — An HTTPS page loading HTTP resources (images, scripts) triggers browser blocks or warnings. Use https:// for all resource URLs, or use protocol-relative URLs (//example.com/image.png).

Set up HSTS — The Strict-Transport-Security header tells browsers to always use HTTPS for your domain. Even if someone types http://, the browser redirects to HTTPS automatically. Once set, it persists for the max-age duration, so apply it carefully.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Local development — localhost is treated as a secure context by most browsers, so browser APIs work without HTTPS. For the rare cases where you need local HTTPS, tools like mkcert generate local certificates.

HTTPS is no longer optional — it's the default. The good news is that the barrier to entry has dropped to nearly zero. But understanding the mechanics behind it makes you much faster at diagnosing security-related issues when they come up.