HomeProjectsBlogContact

HTTPS, SSL and TLS Explained: How Your Site Stays Secure

What actually happens when a browser shows the padlock, how certificates prove identity, why free certificates are just as secure, and how to fix mixed content and expiry problems.

HTTPS, SSL and TLS Explained: How Your Site Stays Secure

Every site should run on HTTPS. That much is common knowledge. What's less common is understanding what HTTPS protects, how certificates work, and what to do when the padlock disappears. A little understanding goes a long way here, because certificate problems tend to show up at the worst possible time.

What HTTPS gives you

HTTPS is HTTP sent over an encrypted TLS connection. (SSL is the older, retired predecessor; people still say "SSL certificate" out of habit.) It provides three guarantees:

  1. Confidentiality: nobody between the user and your server can read the traffic. Not the coffee shop Wi-Fi, not an ISP.
  2. Integrity: nobody can modify the traffic in transit, for example by injecting ads or malicious scripts.
  3. Authentication: the user is talking to the real yoursite.com, not an impostor.

What it doesn't do: protect against bugs in your app, a compromised server or a malicious site that also has a valid certificate. The padlock means "private connection to this domain," not "this site is trustworthy."

How the TLS handshake works (simplified)

When a browser connects:

  1. The browser says hello and lists the encryption methods it supports.
  2. The server replies with its choice and its certificate.
  3. The browser checks the certificate: is it for this domain, still valid, and signed by an authority it trusts?
  4. Both sides use key exchange to agree on shared session keys, without ever sending those keys over the network.
  5. Everything after that is encrypted with the session keys.

Modern TLS 1.3 does this in a single round trip, so HTTPS adds very little overhead today.

Certificates and certificate authorities

A certificate binds a domain name to a public key, and it's signed by a certificate authority (CA). Browsers ship with a list of trusted CAs. If a trusted CA signed your certificate, browsers trust it.

Certificate types you'll see:

  • Domain Validated (DV): proves you control the domain. This is what nearly every site uses.
  • Organization / Extended Validation (OV/EV): includes verified company details. Browsers no longer display these differently in the address bar, so for most sites they offer no visible benefit.
  • Wildcard: covers all subdomains, like *.example.com.

Free certificates are just as secure. Let's Encrypt and similar CAs issue DV certificates for free, using the same encryption as paid ones. Most hosting platforms issue and renew them automatically, with zero effort from you.

Getting HTTPS set up

  • On Vercel, Netlify, Cloudflare and most managed platforms: add your domain and HTTPS is automatic.
  • On your own server: use an ACME client like Certbot, which obtains a Let's Encrypt certificate and configures Nginx or Apache for you. (Deploying to a VPS.)

Certificate lifetimes are short (Let's Encrypt certificates last months, not years, and the industry is moving toward even shorter lifetimes), so automated renewal isn't optional. Check that a renewal timer or cron job exists and test it with a dry run.

After the padlock: finishing the job

  • Redirect HTTP to HTTPS with a permanent redirect, so nobody stays on the insecure version.
  • Add HSTS (Strict-Transport-Security) so browsers only ever use HTTPS for your domain, even if someone types http://. Start with a short max-age, then increase it.
  • Fix mixed content. An HTTPS page that loads scripts, images or stylesheets over http:// triggers warnings or blocked resources. Update URLs to https:// or make them relative. Browser DevTools lists every offender in the console.
  • Mark cookies Secure so they're never sent over plain HTTP. (Security checklist.)

Troubleshooting certificate errors

Error Usual cause
Certificate expired Auto-renewal failed or isn't configured
Name mismatch Certificate doesn't cover this hostname (often www vs apex)
Incomplete chain Server isn't sending the intermediate certificate
Self-signed / untrusted A development certificate made it to production
Works in browser, fails in curl or code Missing intermediate certificate; browsers sometimes fill the gap, other clients don't

Online SSL checkers analyse your configuration and highlight chain problems, weak settings and upcoming expiry. Set up an uptime monitor that also alerts on certificate expiry, so you hear about it weeks before your users do.

HTTPS in local development

You can test HTTPS-only features (secure cookies, service workers, some browser APIs) locally. Tools like mkcert create a locally trusted certificate for localhost in one command, and many frameworks have an --experimental-https style flag or plugin.

FAQ

Is SSL the same as TLS?

TLS is the modern successor to SSL. All current HTTPS uses TLS; "SSL certificate" is just the name that stuck.

Are free SSL certificates safe?

Yes. Free DV certificates from authorities like Let's Encrypt use the same encryption as paid DV certificates. Paid certificates mostly add support, warranties or organisation validation.

Why does my site say "Not secure" even with a certificate?

Usually mixed content (resources loaded over HTTP), an expired certificate, or a certificate that doesn't cover the exact hostname you're visiting.

Keep reading

More from the workbench

All articles →