How HTTPS Works — the TLS handshake explained
How HTTPS works, shown on an interactive canvas: the TLS handshake between browser and server, the certificate authority's role, and the encrypted session that follows.
HTTPS is HTTP running inside an encrypted session. Before a single request travels, the browser and server perform a TLS handshake — negotiate, verify the server's certificate, and agree on a session key only they share.
How HTTPS Works — the TLS handshake explained
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the "TLS handshake" column top to bottom, then the "Secure session" column: negotiation first, encryption after.
- The "Certificate authority" lane is not in the message path — it is the party whose trust the browser uses to judge the server's certificate.
- The "Certificate valid and in date?" decision is the only branch: a valid certificate continues to key exchange, an invalid one ends at the block warning.
The handshake
"Browser connects to the HTTPS site" starts the flow, and "Browser sends a ClientHello with supported ciphers" announces which protocol versions and cipher suites the browser can use. "Server replies with its certificate and a ServerHello" picks from those options and presents its identity — a public-key certificate issued to the domain. That certificate is the entire trust anchor of HTTPS.
Who vouches for the server
"Browser checks the certificate signature against the CA" sits in the "Certificate authority" cluster because the certificate is signed by a CA, and the browser trusts the CA's public key. The "Certificate valid and in date?" decision then tests the three real checks at once: the signature, the domain name on the certificate, and the certificate's expiry and revocation. The "No" branch ends at "Browser blocks the connection with a warning" — the browser preferring to fail closed over loading an unverified site.
The encrypted session
With the certificate trusted, "Browser sends a pre-master secret encrypted with the server's public key" is the one message only the real server can decrypt. From it, "Both sides derive the same session key" explains that the actual data is not encrypted with the certificate keys at all — the certificate protects the key exchange, and a fresh symmetric key protects the conversation. "HTTP messages are encrypted with the session key" and "Browser and server exchange encrypted data" are what HTTPS looks like for the rest of the page load.
Key relationships and takeaways
- HTTPS = HTTP carried over an encrypted TLS session; the encryption happens before any HTTP message.
- Trust comes from the certificate authority, not from the server: the browser judges the server's certificate against a CA it already trusts.
- The certificate's keys are used once, to protect the key exchange; a fresh session key encrypts the actual data.
- An invalid or untrusted certificate stops the connection — HTTPS fails closed rather than sending data unencrypted.
- Everything HTTPS protects travels over the same packet-switched network the internet visual maps.
When to use this visual
- Explaining to a team why the padlock appears and what a certificate warning actually means.
- Onboarding engineers to the handshake before they debug TLS issues, expired certificates or mixed-content warnings.
- Teaching the trust model: how the CA hierarchy and certificate validation protect against impersonation.
How it works
Name your actual certificate issuer
Rename the "Certificate authority" cluster to your provider, and note the certificate type — DV, OV or EV — on the certificate box.
Add the TLS version you run
Annotate the ClientHello step with the protocol versions and cipher suites you actually enable, so the diagram reflects your configuration rather than a generic one.
Draw your failure branches
Add the real outcomes you have seen — an expired certificate, a hostname mismatch, a revoked certificate — each ending in the explicit warning or block it produces.
Split the handshake to the detail you need
If you are teaching TLS 1.3, expand the key exchange into its real messages (Key Share, Finished); the canvas is yours to extend after the open.
Frequently asked questions
What is the difference between HTTP and HTTPS?
HTTPS is HTTP running inside an encrypted TLS connection. The request and response are exactly the same protocol; what changes is that before any HTTP message is sent, the browser and server perform a handshake that establishes an encrypted session. Everything transmitted — URL, headers, cookies, the response body — is readable only by the two ends.
What happens during the TLS handshake?
The browser sends a ClientHello listing the protocols and ciphers it supports; the server replies with its choice and its certificate; the browser verifies the certificate against a trusted certificate authority; and the two sides exchange a secret from which both derive the same session key. After that, HTTP messages flow encrypted. The visual collapses the exchange into those four steps.
Why does the browser need a certificate authority?
Because any server could claim to be any domain. The certificate authority (CA) is the third party that signs the server's certificate after verifying the domain belongs to the applicant. The browser ships with the public keys of trusted CAs, so it can verify the signature itself — that is what turns a self-asserted identity into a vouched-for one.
What does a certificate warning mean?
It means one of the checks in the "Certificate valid and in date?" decision failed — the certificate is expired, covers a different domain, was signed by an untrusted CA, or has been revoked. The browser blocks the connection rather than proceed, because the identity of the site cannot be verified.
Edit this visual in QueryChart (FlowJam)
Open this exact TLS handshake canvas as your own chart, annotate the ciphers you support, and adapt it to your certificate setup.