HTTPS and SSL/TLS Certificates Explained

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.

TLS 1.3 vs TLS 1.2 — What Changed

Both are still in use, but the differences matter.

The biggest improvement is handshake speed. TLS 1.2 requires a 2-RTT (two round trips) handshake. The client says hello, the server sends its certificate, then they exchange keys — two full round trips before encrypted data can flow. TLS 1.3 cuts this to 1-RTT by having the client send key exchange parameters in the very first message.

The cipher suite situation also got cleaned up. TLS 1.2 supported dozens of cipher suites, some of which had known weaknesses — CBC mode, RC4, and others. TLS 1.3 stripped out all the legacy options and kept only proven algorithms: AES-GCM, ChaCha20-Poly1305, and a few others. Fewer choices means fewer ways to misconfigure security.

TLS 1.3 also enables 0-RTT resumption. If you've connected to a server before, you can send data without waiting for a handshake at all. The caveat: 0-RTT data is vulnerable to replay attacks, so it shouldn't be used for sensitive operations like payment processing.

As of 2026, most modern browsers and servers default to TLS 1.3. A growing number of sites are dropping TLS 1.2 support entirely.

Setting Up Let's Encrypt — The Actual Process

The fact that Let's Encrypt is free was covered above. Here's what the setup actually looks like in practice.

The most common client is Certbot. On a Linux server running Nginx or Apache, the whole thing is one command:

sudo certbot --nginx -d example.com -d www.example.com

This single command handles certificate issuance and Nginx configuration. Certbot communicates with Let's Encrypt's servers, verifies domain ownership via HTTP-01 challenge (it places a temporary file on your server that Let's Encrypt checks), fetches the certificate, and updates the server config.

Renewal is automatic too. Register certbot renew in a cron job or systemd timer, and it renews certificates 30 days before expiration. Most Linux distributions set up the renewal timer automatically when you install Certbot.

Wildcard certificates (*.example.com) are also available, but they require DNS-01 challenge — adding a specific TXT record to your DNS. If your DNS provider offers an API, this can be automated as well. Certbot has plugins for Cloudflare, Route 53, and other popular providers.

Of course, if you're on Vercel or Netlify, none of this is necessary. Connect your domain and certificates are handled entirely behind the scenes.

What Developers Should Know

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

Mixed content — More common than you'd think

An HTTPS page loading HTTP resources (images, scripts) triggers browser blocks or warnings. This is called mixed content. Using https:// for all resource URLs fixes it, as does protocol-relative URLs (//example.com/image.png).

The tricky part is that mixed content issues usually come from external sources, not your own code. Old CDN links, third-party widgets, user-submitted image URLs. If you migrate a CMS to HTTPS and users had pasted HTTP image URLs into posts, those all break.

Check Chrome DevTools' Console tab for "Mixed Content" warnings. Setting the Content-Security-Policy: upgrade-insecure-requests header tells the browser to automatically upgrade HTTP requests to HTTPS. But resources that don't actually support HTTPS will still fail — it's a band-aid, not a fix.

HSTS — Powerful but hard to undo

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.

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

What makes HSTS different from a regular server-side 301 redirect: a normal redirect requires the HTTP request to reach your server first, then it sends back a redirect response. HSTS works in the browser itself — the HTTP request never gets sent at all. This blocks man-in-the-middle attacks that could intercept HTTP-to-HTTPS redirects.

The risk: if you set max-age to one year (31536000 seconds) and then remove HTTPS, your site becomes unreachable for that entire duration. Browsers will keep trying HTTPS and failing. Start with max-age=300 (5 minutes) when first deploying, then increase gradually once everything works.

Adding the preload directive and submitting to the HSTS preload list makes browsers enforce HTTPS even on first visit. But getting removed from the preload list can take months, so only do it when you're certain.

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.