Tech & AI, Explained

ssl-and-https

12 min read

SSL / HTTPS

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The padlock in your browser — a system of encryption + trust that makes sure nobody can eavesdrop on, tamper with, or impersonate the site you’re visiting.

In plain English

When you type http://example.com into a browser, the request travels across dozens of computers on its way to the server. Without encryption, anyone along the way — your Wi-Fi neighbor, your ISP, a coffee shop router, a government in the middle — can read every byte. They can also change it: replace a download with malware, inject ads, or rewrite the page.

That’s what plain HTTP is. It’s like sending a postcard: everyone who handles it can read it.

HTTPS (“HTTP Secure”) wraps HTTP inside an encrypted tunnel. The little padlock icon in your address bar means HTTPS is active. Three guarantees are now in play:

  1. Encryption — nobody between you and the server can read the contents.
  2. Integrity — nobody can change the contents without detection.
  3. Authentication — the server has cryptographically proven it really is the owner of example.com, not an impostor.

That third one is what people miss. HTTPS isn’t just “encrypted”; it’s also “verified identity.” The encryption alone would be useless if you didn’t know who you were encrypting to — an attacker could just present themselves as example.com, encrypt everything to themselves, and read it all anyway. The verification step prevents that.

The whole machinery is collectively called SSL/TLS — Secure Sockets Layer / Transport Layer Security. (SSL is the old name, TLS is the modern name. People still say “SSL” out of habit even when they mean TLS.)

Why it matters

Three reasons, in order of bluntness:

  1. Browsers now actively shame plain HTTP. Modern Chrome shows a big “Not Secure” warning on any non-HTTPS page that takes input. Many features (Service Workers, camera/mic access, push notifications, HTTP/2, HTTP/3) only work over HTTPS. Plain HTTP is functionally a deprecated protocol for any real site.

  2. Search engines rank HTTPS higher. Google has used HTTPS as a ranking signal since 2014. A site on plain HTTP loses SEO ground for no other reason.

  3. The real reason: user safety. Passwords, sessions, payment forms, anything personal — without HTTPS, all of it is on a postcard. Compromised Wi-Fi in airports and cafés would be a goldmine for attackers if HTTPS didn’t exist.

In 2026, HTTPS is the default for the entire web. The conversation isn’t “should I use HTTPS?” — it’s “which of the four ways do I get a certificate, and how do I keep it from breaking?”

How HTTPS actually works (the TLS handshake)

When your browser connects to https://example.com, this dance happens before any actual page content moves:

1. Browser → Server:  "Hi, I'd like to talk securely.
                       I support these encryption methods: [list].
                       Here's a random number."

2. Server → Browser:  "Hello. Let's use [chosen method].
                       Here's my certificate proving I'm example.com.
                       Here's my random number."

3. Browser:           Checks the certificate:
                      - Is it valid for "example.com"?
                      - Is it signed by a trusted CA?
                      - Hasn't expired? Hasn't been revoked?
                      If anything fails → big scary warning, connection refused.

4. Browser ↔ Server:  Use public-key crypto to agree on a shared session key.
                      All subsequent traffic is encrypted with that key.

5. Browser → Server:  "GET / HTTP/2"   (now encrypted)
   Server → Browser:  "<the actual page>"  (now encrypted)

This handshake adds latency — roughly one extra round trip the very first time you connect. TLS 1.3 (the current standard) cuts this further, and session resumption + 0-RTT can eliminate the handshake on repeat visits. On a fast connection, the human-visible cost of HTTPS in 2026 is nil.

The certificate — what it actually is

A TLS certificate is a small file (a few KB) that contains:

  • The domain name(s) it’s valid for
  • A public key
  • The issuer (which CA signed it)
  • A validity period (start and end dates)
  • A cryptographic signature from the CA

The certificate is public — anyone can fetch it from a server. What makes it trustworthy is the matching private key, which the server keeps secret. During the handshake, the server proves possession of the private key, and the certificate proves the public key belongs to the right domain.

You can inspect any site’s certificate by clicking the padlock icon in any browser. Try it on vercel.com — you’ll see the issuer (currently Let’s Encrypt), the validity dates, the alternative names (often a wildcard like *.vercel.com).

Certificate Authorities (CAs) — who you trust

A certificate is only useful if the verifier (the browser) trusts the signer. Browsers ship with a built-in list of trusted Certificate Authorities (CAs) — companies and nonprofits whose root certificates are baked into the browser/OS.

If a CA signs a certificate, the browser believes it. If an unknown party signs one, the browser refuses.

The major CAs:

CANotes
Let’s EncryptFree, automated, the dominant CA on the open web. Most modern hosting uses this.
DigiCertCommercial. Used by big enterprises. Costs money.
GlobalSignCommercial.
Sectigo (formerly Comodo)Commercial.
Google Trust ServicesFree for Google Cloud customers; also issues certs broadly.
ZeroSSLFree + paid tiers, alternative to Let’s Encrypt.
CloudflareIssues certs for sites behind Cloudflare. Uses ECC by default.

For 99% of webapps in 2026, Let’s Encrypt is the right answer, and your hosting provider handles it for you so transparently you may not even realize what CA you’re using.

How modern hosting gives you HTTPS for free

The big shift since 2016: hosting providers now provision certificates automatically. The process behind the scenes:

  1. You add your domain to your host (Vercel, Netlify, Cloudflare, etc.)
  2. The host runs an ACME client (Automatic Certificate Management Environment — the protocol Let’s Encrypt uses)
  3. The ACME client proves to Let’s Encrypt that you control the domain — usually by either:
    • HTTP-01 challenge: The CA pings http://yourdomain.com/.well-known/acme-challenge/<random>, and your host serves the right response
    • DNS-01 challenge: The CA asks for a specific TXT record at _acme-challenge.yourdomain.com, your host adds it
  4. Let’s Encrypt issues a certificate
  5. Your host installs it and configures HTTPS on your domain
  6. Roughly every 60 days, the host repeats the dance to renew before the cert expires

You see none of this. You just see the padlock appear within minutes of pointing your domain at the host.

A concrete example: the moment HTTPS kicks in

Watch the network panel in DevTools when you visit https://stmarkbible.com:

Request 1 (timing):
  DNS lookup ............ 12ms
  Initial connection .... 41ms
  SSL handshake ......... 95ms    ← TLS happens here
  Request sent .......... 0.5ms
  Waiting (TTFB) ........ 78ms
  Content download ...... 18ms

Total: ~245ms

The “SSL handshake” line is your TLS handshake. After that, every byte of every HTTP request and response is encrypted.

If you look at the certificate (click the padlock → Connection is secure → Certificate is valid), you’ll see:

  • Issued to: stmarkbible.com, also valid for *.stmarkbible.com (wildcard)
  • Issued by: Let’s Encrypt R3
  • Valid from / to: ~90 day window
  • Algorithm: SHA-256 with ECDSA (modern, elliptic-curve)
  • Public key: the public half of an asymmetric keypair

George never thought about any of this. Vercel did it.

HSTS — telling browsers to never accept HTTP again

A subtle attack: a user types example.com (without https://) into the browser. The browser tries http://example.com first. If an attacker is on the same Wi-Fi, they can intercept this initial HTTP request before the server has a chance to redirect to HTTPS — and then proxy the rest of the connection while serving malicious content. This is called SSL stripping.

HSTS (HTTP Strict Transport Security) fixes this. It’s a response header your server sends:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Translation: “for the next two years, the browser must always use HTTPS for this domain — never even attempt HTTP.” Once the browser sees this header once, the protection kicks in.

The preload part is even stronger: it asks browsers to bake the rule into their source code, so even the very first visit is guaranteed HTTPS-only. You submit your domain at hstspreload.org to get added.

For Bible Quest and most modern webapps, HSTS is enabled by default by the hosting platform. You don’t have to think about it — but you should know it exists, because once you preload a domain you can’t easily un-preload.

Certificate types — DV, OV, EV

The certificates Let’s Encrypt issues are DV (Domain Validation) certificates. The CA proves you control the domain, nothing more. They’re free, fast, and perfectly adequate for almost everything.

You may also encounter:

  • OV (Organization Validation) — the CA also verifies the legal entity behind the domain. Takes a few days, costs money. Used by some banks and corporates.
  • EV (Extended Validation) — heavy verification of the legal entity. Used to make the address bar turn green and show the company name. Browsers have largely removed this UI in 2020+, so EV is now mostly legacy.

For solo developers and small teams: DV via Let’s Encrypt covers everything. Don’t pay for OV/EV unless you have a specific compliance reason.

Wildcard and SAN certificates

A certificate can cover multiple names:

  • Single-name: stmarkbible.com only.
  • Multi-domain (SAN): Subject Alternative Names — lists several explicit domains: stmarkbible.com, www.stmarkbible.com, bible.stmarkbible.com.
  • Wildcard: *.stmarkbible.com — matches ANY single subdomain (blog.stmarkbible.com, api.stmarkbible.com, etc.). Does NOT match the apex or nested subdomains (api.staging.stmarkbible.com is not covered).

Let’s Encrypt issues both single-name and wildcard certs. Wildcards require DNS-01 challenges (you must control DNS), which is why some hosts issue wildcards only when DNS is managed at the same place.

Common gotchas

  • Mixed content blocks pages from loading. An HTTPS page that embeds an HTTP image, script, or stylesheet will have those resources blocked by modern browsers. Always use protocol-relative URLs (//example.com/img.jpg) or explicit HTTPS in your code.

  • localhost is treated as secure even without a real certificate. Service Workers and other secure-context-only APIs work on localhost. But 127.0.0.1 and 192.168.x.x may behave differently across browsers. If you’re testing secure-context features, use localhost literally.

  • Self-signed certificates make browsers panic. If you generate your own cert for testing, browsers will show a big red warning. You can manually trust it, but never do this in production.

  • Certificate expiration is silent until it isn’t. A cert expires at midnight; the site is fine at 11:59, then suddenly returns “Your connection is not private” to every visitor at 00:00. Always set up monitoring (StatusCake, Better Uptime, or your host’s own renewal alerts).

  • Auto-renewal can fail quietly. The ACME challenge might fail because your DNS changed, a firewall rule changed, or your host is misconfigured. Most managed hosts catch this and email you, but check your DNS configuration when changing hosts.

  • Cloudflare’s free SSL is fine for most cases but adds an interesting wrinkle. “Flexible” SSL encrypts only between user and Cloudflare; Cloudflare → origin is plain HTTP. This protects user data on Wi-Fi but is not true end-to-end encryption. Use “Full (strict)” mode whenever your origin supports HTTPS — which is always with Vercel et al.

  • CAA records can block certificate issuance. If you’ve set a CAA record (which restricts which CAs can issue certs for your domain), make sure it includes your host’s CA. Otherwise renewals fail.

  • Renewing too often hits Let’s Encrypt rate limits. 50 certs per domain per week, 5 duplicates per week, 300 New Orders per account per 3 hours. You should never hit these accidentally, but if you’re scripting cert issuance, know the limits.

  • HTTP-01 challenges break behind authentication. If your site requires login to even load /, the Let’s Encrypt server can’t reach the challenge file. Whitelist /.well-known/acme-challenge/* from any auth wall.

  • Renaming a domain doesn’t transfer certificates. New domain = new cert issuance. Plan for the brief window during a DNS switchover when the new domain has DNS but no cert yet.

  • HSTS preload is sticky. Once your domain is on the browser preload list, you cannot serve plain HTTP for it. If you ever need to (an internal staging environment, an emergency), you’re stuck. Preload only when you’re sure.

  • www vs apex certs. Your cert must cover the exact name the user typed. A cert for example.com does NOT cover www.example.com unless www.example.com is also listed (SAN) or there’s a wildcard. Almost every host adds both automatically; double-check if you’re rolling your own.

  • TLS 1.0 and 1.1 are dead. Browsers, payment processors, and security scanners reject them. Make sure your host serves TLS 1.2 minimum, TLS 1.3 ideally. Managed hosts handle this; self-managed servers need configuration (Mozilla SSL config generator helps).

  • Cipher suites still matter at the edges. For most users, the host’s defaults are fine. For PCI compliance, government, or security-conscious organizations, audit which ciphers your server accepts. SSL Labs (ssllabs.com/ssltest/) is the canonical scanner.

  • The padlock means “encrypted and verified,” not “trustworthy.” A scam site with a valid Let’s Encrypt cert still gets a padlock. The padlock proves nobody is tampering with the connection — not that the site is honest. Educate users accordingly.

See also

Sources

Graph View

Backlinks