Guide

TLS and HTTPS explained

Every time you see a padlock beside a URL, HTTPS is protecting the connection between your browser and the server. Under the hood, TLS (Transport Layer Security) encrypts data in transit, proves you reached the real site, and detects tampering. This guide walks through how that works — certificates, certificate authorities, the TLS handshake, common deployment mistakes, and why HTTPS is table stakes for any site that connects wallets, processes payments, or serves JavaScript that can move money.

HTTP vs HTTPS in plain language

HTTP (Hypertext Transfer Protocol) is the request/response language browsers and servers speak. By itself it is plaintext: anyone on the same Wi-Fi, ISP path, or compromised router can read usernames, cookies, API keys, and page content. HTTPS is HTTP wrapped inside TLS. The URL scheme changes from http:// to https://, and port 443 is used instead of 80.

TLS provides three properties modern sites depend on:

Confidentiality — eavesdroppers see encrypted noise, not JSON or HTML.
Integrity — altered bytes fail verification; attackers cannot silently change responses.
Authentication — the server presents a certificate chaining to a trusted root, binding the connection to a domain name.

Browsers now mark plain HTTP as "Not secure" and may block powerful APIs on non-HTTPS origins. Search engines also prefer HTTPS pages. For publishers, that affects crawlability and user trust — see our Core Web Vitals guide for how transport security intersects with performance signals.

TLS vs SSL — same job, updated names

People still say "SSL certificate" because SSL (Secure Sockets Layer) was the original protocol. SSL 2.0 and 3.0 are broken and disabled everywhere. TLS 1.2 and TLS 1.3 replaced them. When you buy or generate a cert today, it is a TLS certificate — the legacy label stuck in marketing.

Modern servers should negotiate TLS 1.2 minimum, prefer TLS 1.3 where clients support it, and disable weak cipher suites. Hosting panels and reverse proxies (nginx, Caddy, Cloudflare) expose cipher and protocol knobs; defaults on major CDNs are usually sane, but self-managed VPS setups need explicit tuning.

How the TLS handshake works

Before any HTTP request flies, client and server perform a handshake to agree on keys. TLS 1.3 completes in one round trip in the common case (faster than older TLS versions). At a high level:

ClientHello — the browser advertises supported TLS versions, cipher suites, and extensions (including SNI — the hostname it wants).
ServerHello + certificate — the server picks parameters and sends its certificate chain plus proof it holds the private key.
Key agreement — both sides derive shared session keys using elliptic-curve Diffie-Hellman (or similar). The private key never crosses the wire.
Encrypted application data — HTTP requests and responses flow inside the encrypted tunnel.

If the certificate does not match the hostname, is expired, or chains to an unknown root, the browser shows a interstitial warning and refuses to load the page until you override — which you should almost never do on a site that asks for wallet access.

Forward secrecy

Ephemeral key exchange means that even if someone records encrypted traffic and later steals the server's long-term private key, they cannot decrypt past sessions. That is why TLS 1.3 removed static RSA key transport. Forward secrecy is one reason upgrading old nginx configs matters.

Certificates and certificate authorities

A TLS certificate is a signed document binding a public key to one or more domain names (SAN entries). Your server keeps the matching private key secret; the certificate is public.

Certificate authorities (CAs)

Browsers ship with a trust store of root CAs. A certificate authority validates that you control a domain — via DNS TXT record, HTTP challenge file, or email to admin@ — then signs your certificate. Intermediate CAs bridge roots to end-entity certs so root keys stay offline.

Certificate types you will see

Domain Validation (DV) — proves domain control only; sufficient for most sites.
Organization Validation (OV) / Extended Validation (EV) — extra business identity checks; EV no longer gets special green-bar UI in modern Chrome.
Wildcard — covers *.example.com (one label deep).
Multi-domain (SAN) — several hostnames on one cert.

Let's Encrypt popularized free, automated DV certificates via the ACME protocol. Tools like Certbot, Caddy, and Traefik renew certs before expiry (typically every 60–90 days). For a static site on a VPS, pairing nginx with Certbot is the standard pattern: HTTP-01 challenge on port 80, then redirect everything to HTTPS.

HSTS, redirects, and mixed content

Always redirect HTTP to HTTPS

Serving the same site on both schemes lets attackers downgrade users to plaintext. Configure a 301 redirect from port 80 to 443 at the edge. Test with curl -I http://yourdomain and confirm a single hop to HTTPS.

HTTP Strict Transport Security (HSTS)

The Strict-Transport-Security response header tells browsers to remember "only HTTPS for this host" for a max-age period. Optional includeSubDomains and preload tighten coverage. HSTS closes the first-visit downgrade window after users have seen the header once. Submit eligible domains to the browser preload list only when every subdomain is HTTPS-ready.

Mixed content

An HTTPS page that loads scripts, styles, or images over http:// creates mixed content. Browsers block active mixed content (JavaScript) because it negates encryption — an attacker could inject wallet-draining code. Passive mixed content (images) may load with warnings. Fix by using relative URLs, protocol-relative paths, or upgrading every asset to HTTPS. Content Security Policy can help enforce upgrades — see our CSP guide.

HTTPS for dApps, wallets, and payment flows

Wallet extensions and mobile deep links assume a trustworthy origin. Phishing sites clone legitimate UIs on look-alike domains served over HTTPS with their own valid certs — TLS authenticates the domain, not the operator. Users must still verify the URL. HTTPS does stop network attackers from swapping JavaScript mid-flight.

Practical checklist for crypto-facing sites:

Serve the entire app over HTTPS with valid, auto-renewed certificates.
Pin API and RPC calls to HTTPS endpoints; wallets block mixed content fetches to insecure RPC URLs from secure pages.
Set restrictive CSP — especially script-src — so XSS cannot exfiltrate seeds or trick signatures.
Use Secure and HttpOnly flags on session cookies if you have server-side auth alongside wallet connect.
Never ask users to paste seed phrases; HTTPS does not make that safe.

Merchants accepting Solana Pay or wallet transfers should treat TLS as the transport layer under their verification logic — our accept Solana payments guide covers on-chain confirmation after the browser loads your checkout page securely.

TLS termination and reverse proxies

Large deployments often terminate TLS at a load balancer or CDN, then forward plaintext HTTP to app servers on a private network. That is fine if the hop between edge and origin is trusted (VPC, not the public internet). Misconfigured "flexible SSL" modes that accept HTTPS from users but talk HTTP to origin over the public internet reintroduce plaintext risk.

When your SPA calls APIs on another subdomain, CORS and TLS both matter — browsers enforce HTTPS for fetch to secure origins. Our CORS guide explains the header side; ensure every API host presents a valid cert matching its name.

Common mistakes and how to fix them

Expired certificate — automate renewal; monitor expiry (30-day alerts).
Hostname mismatch — cert must cover www and apex, or redirect one to the other consistently.
Incomplete chain — serve intermediate certs; some Android clients fail without them.
TLS only on homepage — every path, asset, and API must be HTTPS.
Self-signed certs in production — fine for local dev; users will not trust them on the public web.
Ignoring security headers — pair TLS with CSP, HSTS, and sensible Referrer-Policy.

Wallet users should also practice domain hygiene: bookmark real sites, verify punycode homographs, and read extension connection prompts. Transport security complements — but does not replace — the practices in our wallet security guide.

Key takeaways

HTTPS is HTTP inside TLS, providing encryption, integrity, and server authentication.
Certificates bind public keys to domain names; CAs vouch after domain-control checks.
The TLS handshake negotiates keys; TLS 1.3 is faster and mandates forward secrecy.
HSTS and HTTP-to-HTTPS redirects prevent downgrade attacks; fix mixed content so scripts cannot be injected over HTTP.
Crypto and payment sites need HTTPS end-to-end plus strong CSP — TLS alone does not stop phishing or XSS.