How HTTPS Works: an editable mindmap
Explore How HTTPS Works as an editable mindmap. Follow color-coded branches for Browser hello, Server identity, Session keys, Encrypted traffic, with supporting ideas and curved connections.
A mindmap of How HTTPS Works, with the main ideas arranged around a central topic and connections that show how they relate.
How HTTPS Works: an editable mindmap
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this mindmap
- Begin at “How HTTPS Works” in the centre, then explore any branch that answers your question. The branch colors keep each group of ideas together.
- Curved lines show relationships; arrowheads appear only where one idea leads to another. Select any idea in the editor to change its text, position, or connections.
Browser hello
This branch brings together “Browser connects to the HTTPS site”, “Browser sends a ClientHello with supported ciphers”.
Server identity
This branch brings together “Server replies with its certificate and a ServerHello”, “Validity also checks the domain name on the certificate matches the site and that the certificate has not expired or been revoked.”, “Browser blocks the connection with a warning”, “Browser checks the certificate signature against the CA”.
Session keys
This branch brings together “Browser sends a pre-master secret encrypted with the server's public key”, “From the pre-master secret, both sides independently compute the same session key. Only this key encrypts the actual data — the certificate's keys are used once.”.
Encrypted traffic
This branch brings together “HTTP messages are encrypted with the session key”, “Browser and server exchange encrypted data”.
Connections across the map
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.
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
Start at the central topic
Rename “How HTTPS Works” if you want to adapt this map to a specific project or lesson.
Develop the branches
Edit the supporting ideas, then add examples and notes where a branch needs more detail.
Connect related ideas
Draw curved connections across branches; use an arrow only when the relationship has a direction.
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 mindmap in QueryChart
Open this mindmap as your own editable free canvas. Move ideas, add branches, and draw new connections.