How TLS and HTTPS certificate chains work

What TLS actually guarantees

TLS sits between TCP and HTTP. Before any HTML or JSON arrives, client and server negotiate cryptography that delivers three properties:

• Confidentiality — passive eavesdroppers on Wi-Fi or ISP links see ciphertext, not passwords or session cookies.
• Integrity — tampering with ciphertext is detected; attackers cannot silently rewrite API responses mid-flight.
• Authentication — the server presents a certificate; the client verifies the chain and checks the hostname matches.

TLS does not guarantee the server is honest. A correctly certified phishing site at solana-garden.evil.com still has valid HTTPS for its name. Users defeat that with bookmarks, passkeys bound to origins (see our passkeys explainer), and skepticism about transaction previews in wallets.

The TLS 1.3 handshake in plain language

Modern browsers prefer TLS 1.3, which completes in one round trip after TCP connects. Older TLS 1.2 needed extra flights; you still see it on legacy enterprise gear.

1. ClientHello — Your browser sends supported cipher suites, TLS version, and a random nonce. It may include server_name (SNI) so the host can pick the right certificate on shared IPs.
2. ServerHello + certificate — The server picks parameters, sends its certificate chain (leaf + intermediates), and proves it holds the private key matching the leaf public key.
3. Key agreement — Both sides derive shared session keys (usually via ephemeral Diffie-Hellman). Forward secrecy means recorded ciphertext cannot be decrypted later if the long-term certificate key leaks.
4. Encrypted application data — HTTP requests and responses flow inside the encrypted tunnel. Headers like Authorization and wallet session tokens ride here — which is why OAuth tokens must never appear in URLs.

Browsers also negotiate ALPN (Application-Layer Protocol Negotiation) so the same port 443 can serve HTTP/2 or HTTP/3 after TLS completes. WebSockets and SSE upgrades reuse the TLS session established for the initial HTTPS page load.

Certificate chains: leaf, intermediate, root

A public website certificate is rarely signed directly by a root CA. Roots stay offline in hardware; day-to-day issuance flows through intermediate CAs. Your browser receives a chain like:

• Leaf (end-entity) certificate — Names the site (solana.garden, *.example.com). Contains the public key the server uses for TLS. Signed by an intermediate.
• Intermediate CA certificate(s) — One or more signing authorities between leaf and root. Sent by the server during the handshake so the client can build a path.
• Root CA certificate — Pre-installed in your OS or browser trust store (Mozilla, Apple, Microsoft programs). Not sent over the wire — the client already has it.

Verification walks the chain: check each signature, check validity dates, check the leaf's Subject Alternative Names include the hostname you typed, and ensure no certificate is revoked. Free automated issuance from Let's Encrypt still produces the same chain shape; only the CA brand and validation policy differ from paid extended-validation certs.

How browsers decide to trust

Trust is not magic — it is a curated list plus math:

• Trust store — Hundreds of root CAs ship with your OS. Compromise of any root can forge certificates for any domain until the root is distrusted in an emergency update.
• Hostname verification — The leaf must match the URL. Wildcards cover one level (*.garden matches api.garden but not a.b.garden).
• Revocation — OCSP (Online Certificate Status Protocol) asks the CA whether a cert is still valid. OCSP stapling lets the server attach a fresh OCSP response to the handshake, saving the client a round trip. CRL (Certificate Revocation Lists) are older bulk downloads rarely used alone today.
• Certificate Transparency — Public CT logs record issued certs. Mis-issued certs for your domain show up in monitoring tools even before users are attacked.

Enterprise networks sometimes install a custom root to inspect HTTPS traffic on corporate laptops. That is intentional TLS interception — fine on a managed work machine, dangerous if you do not know it is there. The same mechanism explains why TLS client fingerprints differ between Chrome builds and can identify traffic without cookies.

Common HTTPS failures users actually see

DevOps tickets and browser interstitials repeat the same patterns:

• Expired certificate — The leaf's notAfter date passed. Automation (Certbot, ACME clients) prevents this when renewals are monitored.
• Hostname mismatch — Cert issued for www.example.com but user visits example.com, or a stale cert after a CDN cutover.
• Incomplete chain — Server sends only the leaf; Android or older Java trust stores fail because they cannot fetch missing intermediates.
• Self-signed or private CA — Fine for localhost; browsers block it on the public internet unless you manually trust the cert (which you should not do for random sites).
• Mixed content — An HTTPS page loads http:// scripts or images. Modern browsers block active mixed content; passive images may still warn. Breaks wallet dApps that pull legacy HTTP APIs.
• Clock skew — Client device time wrong by hours makes valid certs look expired. Common on VMs and cheap hardware.

The scary full-page warning exists because continuing bypasses authentication — you would encrypt traffic to an unknown party. For high-value flows (wallet connect, exchange login), stop and fix the cert instead of clicking through.

TLS vs blockchain signatures

Both use public-key cryptography, but the jobs differ:

• TLS server keys — Prove the HTTPS endpoint you reached controls a domain name for this session. Keys rotate with cert renewals; compromise affects transport, not on-chain balances.
• Wallet keys — Authorize token transfers on a public ledger. No CA signs your Solana keypair; trust is math plus your custody of the seed phrase.
• Who verifies? Browsers verify TLS chains automatically. Solana validators verify transaction signatures against on-chain account keys — see verify Solana payments for reading those signatures in explorers.

A perfect HTTPS connection to a malicious dApp still cannot steal funds unless you approve a bad transaction in your wallet. Conversely, a legitimate dApp on HTTP (no TLS) exposes session tokens and RPC traffic to network attackers — always treat non-HTTPS wallet sites as broken infrastructure.

What operators should monitor in 2026

If you run a site or API:

• Automate renewal 30 days before expiry; alert on ACME failures.
• Serve the full chain from nginx, Caddy, or your CDN — test with SSL Labs or openssl s_client.
• Enable HSTS only when HTTPS is stable everywhere — it tells browsers to refuse HTTP for your domain.
• Prefer TLS 1.3; disable obsolete ciphers (3DES, RC4, export suites).
• Subscribe to CT alerts for your domain; investigate unexpected cert issuance immediately.

Related on Solana Garden: HTTP caching explained, OAuth 2.0 and OIDC, Browser fingerprinting, Solana wallet security, Explainers hub.