HTTPS and TLS explained: the security basics small sites skip

A padlock icon told a client's visitors their site was secure, but their payment processor's fraud team kept flagging checkout as an "insecure origin." The site had HTTPS enabled, but the TLS configuration still allowed a cipher suite from 2011 and shipped no security headers at all. The padlock doesn't tell you any of that — it only confirms encryption exists, not that the configuration behind it is sound.

What actually happens during the handshake

When a browser connects over HTTPS, it and the server run a TLS handshake: the server presents a certificate signed by a trusted certificate authority, the browser checks that signature against a list baked into the OS or browser itself, and both sides then negotiate a shared symmetric key for the session. Everything after that point is encrypted with the fast symmetric key, which is why HTTPS doesn't meaningfully slow a page down despite the extra step at connection time.

Certificate tiers, and which one you actually need

Domain Validation certificates only prove control of the domain and can be issued automatically in minutes — this is what Let's Encrypt provides free, and it's sufficient for the overwhelming majority of sites. Organization Validation adds legal-entity verification, and Extended Validation requires a much deeper business check. Browsers stopped visually distinguishing EV certificates around 2019, so for most small sites the extra cost of OV or EV buys paperwork for enterprise procurement checklists, not a better visitor experience.

HSTS closes the gap HTTPS leaves open

Even with HTTPS configured, a browser's very first request to your domain often goes out over plain HTTP by default before redirecting. The Strict-Transport-Security header tells browsers, after one successful visit, to never attempt an HTTP connection to your domain again for a set duration — closing the narrow window where a network attacker could intercept that first request. Setting a long max-age with the includeSubDomains directive is a five-minute config change with a genuine security payoff.

The headers nobody remembers to add

Content-Security-Policy restricts which scripts and resources a page can load, shrinking the blast radius of a cross-site scripting bug. X-Content-Type-Options: nosniff stops browsers from guessing file types in an exploitable way. Referrer-Policy controls how much of your URL leaks to external sites through outbound links. Permissions-Policy restricts which browser features, like camera or location, a page can even request. None of these touch application code — they're server or CDN configuration only.

Mixed content quietly breaks the padlock

A page served over HTTPS that loads even one image, script, or stylesheet over plain HTTP shows a broken padlock in most browsers, and modern browsers block mixed active content like scripts outright. This usually creeps in through an old hardcoded http:// link buried in a theme or third-party widget. Check your live site's developer console for mixed-content warnings after any redesign or migration.

Don't trust the padlock — test the actual configuration

Qualys SSL Labs' free SSL Server Test grades your TLS setup and flags outdated protocol versions like TLS 1.0/1.1, weak cipher suites, and certificate chain problems. securityheaders.com does the equivalent for your HTTP response headers. Both take under a minute and routinely surface issues on sites that looked completely fine at a glance.

Certificate pinning is a trap for most sites

Pinning locks a site or app to trust only one specific certificate or public key, which sounds like extra protection but creates a real operational risk: if that pinned certificate needs emergency replacement and the pin isn't updated everywhere in time, you lock out your own legitimate users. It's appropriate for high-security mobile apps with tightly controlled update cycles, and a liability for most ordinary websites.

Subresource Integrity protects against a compromised CDN

When you load a script from a third-party CDN, adding an integrity attribute with a cryptographic hash of the expected file lets the browser refuse to run that script if the CDN gets compromised and serves altered code — something that has happened to well-known CDNs in the past. It costs one extra attribute per script tag and closes a supply-chain gap that HTTPS alone doesn't cover.

Certificate transparency logs as a free monitoring tool

Every publicly trusted certificate issued for your domain gets logged in a public, searchable certificate transparency log, and a service like crt.sh lets you check that log for free. This catches something HTTPS itself can't prevent: someone fraudulently obtaining a certificate for your domain through a compromised registrar or DNS account. Checking periodically, or setting an alert, catches domain-level compromise early.

Frequently asked

Is a free Let's Encrypt certificate weaker than a paid one? No — encryption strength is identical. Paid certificates buy longer validity, warranty guarantees, and sometimes OV/EV identity verification, not stronger cryptography.

Do purely informational sites with no forms need HTTPS? Yes — browsers flag any HTTP page as "Not Secure" regardless of content, search engines use HTTPS as a minor ranking signal, and it stops intermediate networks from tampering with or injecting ads into your traffic.

How often do certificates need renewal? Let's Encrypt certificates last 90 days and are meant to renew automatically via a tool like certbot; commercial certificates typically run one year under current industry-wide validity limits.

Does HTTPS alone prevent a data breach? No — it protects data in transit, not data at rest in your database, weak admin passwords, or vulnerable plugins. It's one layer of a much larger security posture.