Prefer to click through the interactive model?
TLS and certificates — study guide
The same fragments the interactive model serves, read in order. One source, two views.
The padlock does two jobs
The little padlock an address bar shows looks like a single promise, but it stands for two separate ones, and confusing them is the usual mistake. TLS (Transport Layer Security) makes a connection both private and authenticated: private, because everything sent is encrypted so an eavesdropper on the wire learns nothing; authenticated, because the machine at the other end has proven it is the real server for the name you asked for, not an impostor.
Encryption without authentication would be worthless here. A perfectly private conversation with the wrong party is still a conversation with the wrong party, and the whole point of https:// is to rule that out before any password or page contents move. TLS runs on top of an ordinary TCP connection at the transport layer; the padlock is what appears once TLS has finished both jobs over that connection.
Those two jobs lean on different machinery. Encryption needs a shared secret that only the two ends know; authentication needs a way to prove identity to a stranger you have never met. TLS builds both during a brief opening exchange, and the certificate a server presents is what turns "some encrypted connection" into an encrypted connection to the party you actually meant.
A key you share and a key you keep
The trick that makes the whole thing possible is a key that comes in two matching halves. One half is the private key, which its owner generates and never shares with anyone. The other is the public key, which is meant to be handed out freely: posted, mailed, printed on a billboard, it does not matter who holds it. The two halves are bound together, but holding the public key does not let anyone work out the private one.
What the pair buys you is a signature. The holder of the private key can run it over a message to produce a small mark, and anyone holding the matching public key can check that mark against the message. The check answers exactly one question: was this signed by the private key that matches this public key? Only the private key can produce a mark that passes the check like a wax seal only your own ring can press: anyone can recognize it, but no one else can reproduce it, and the public key can only verify a signature, never forge a fresh one.
That asymmetry is the whole foundation of proving identity over a network. If you trust that a certain public key belongs to a certain server, then a signature that verifies against that public key is proof you are talking to something that holds the matching private key: the real server, not a copy. So sign with the private key, verify with the public key. Much of the rest of TLS is about getting you a public key you can trust, so that this single check means what you want it to.
Agreeing on secrets before the first word
Before a single byte of the actual request is sent, the two ends run a short opening exchange called the handshake, and its job is to turn a bare TCP connection into a private, authenticated one. It happens in a fixed order. The client speaks first with a ClientHello, offering the TLS versions and ciphers it supports. The server answers with a ServerHello that picks the version and cipher both sides will use.
In the same breath the server sends its Certificate, the document that carries its public key along with a claim about who it is. Client and server then run a key agreement, a step that lets both sides arrive at the same secret session key without ever sending that key across the wire, so an eavesdropper watching every packet still cannot derive it. Each side sends a Finished message to confirm the handshake was not tampered with, and only then does encrypted application data begin to flow.
The current version, TLS 1.3, is quick about all of this: it completes the handshake in a single round trip, so the secret is agreed and the first encrypted request can follow almost immediately. What you get at the end is one connection that is both secret and tied to a proven identity, the two promises the padlock stands for.
Binding a name to a key
A public key on its own is anonymous. It proves whoever holds the matching private key signed something, but it says nothing about who that holder is. A certificate fixes exactly this. It is a small signed document, in a standard format called X.509, that binds a specific name, such as a domain name, to a specific public key, and carries the signature of the party that issued it.
Because the binding is signed by an issuer, a certificate is only as convincing as your trust in that issuer like an identity card, convincing only because a party you trust issued and stamped it. A certificate also states a validity period, a start and end date outside which it should not be accepted. During the handshake the server presents its certificate, and that is how the client learns which public key to expect: not by taking the server's word for it, but by reading a name-to-key binding that someone has vouched for.
This is the join between the two halves of the story. A key pair gives you a way to check signatures; a certificate tells you whose public key you are holding and who is willing to swear to it. What remains is the harder question of why you should trust the issuer at all.
Why you believe the certificate
Trusting a certificate would be impossible if every server's certificate had to be signed by an issuer you personally knew. Instead, trust is passed along a chain like being vouched for by someone whom a person you already trust vouches for in turn. The certificate a server presents, called the leaf, is signed by a certificate authority; that authority's own certificate, usually an intermediate, is signed in turn by another; and the chain climbs until it reaches a root.
The root is the part your device already trusts. Every operating system and browser ships with a preinstalled set of root certificates, the trust store, chosen and vetted in advance. A leaf you have never seen becomes believable because it is signed by an intermediate, which is signed by a root sitting in that store. Trust in a handful of preinstalled roots extends, link by link, to millions of leaf certificates, none of which had to be known ahead of time.
This is why a certificate can be issued for a brand-new site this morning and be trusted by your laptop this afternoon with no update at all: the laptop never needed to know the leaf, only to trace a signed path from it up to a root it was already carrying.
The checks before the lock closes
When the server presents its certificate, the client runs a set of checks before it will trust the connection, and every one of them happens on the client itself. First, the signatures: the client follows the chain from the leaf up through each issuer and confirms every link is validly signed, ending at a root already in its trust store. Second, the dates: the certificate must be inside its validity period, neither expired nor not-yet-started. Third, the name: the certificate must actually be issued for the site being visited, not some other domain.
The point worth stating precisely is that this validation is local. The client checks the presented chain against the roots it already holds; it does not contact the certificate authority to ask whether the certificate is good. The authority did its work earlier, when it signed the certificate, and that signature is what the client verifies offline. (A client may separately check whether a certificate has been revoked, but that is a distinct mechanism and not part of proving the chain during the handshake.)
Only when all three checks pass does the encrypted session proceed. If any of them fails, a broken chain, an expired date, a name that does not match, the client refuses, which is exactly the certificate warning a browser throws up instead of the page.
What the lock does and does not hide
TLS gives three concrete guarantees, and it is worth being exact about each. Confidentiality: the contents of the connection are encrypted, so an observer on the wire cannot read them. Integrity: those contents cannot be quietly altered in transit without the tampering being detected. Server authentication: the certificate check proves you are connected to the real server for the name you asked for. Together these are strong, but they are not everything.
What TLS does not hide is who you are talking to. The destination IP address is right there in every packet, because the network has to know where to deliver them, so anyone watching can see which server you reached. Usually the hostname leaks too: the client announces the name it wants near the start of the handshake, in a field called SNI (Server Name Indication), and in standard TLS that name is sent in cleartext before encryption is established. The fact that a connection happened, and to whom, is visible even when its contents are not.
The distinction matters for reasoning about privacy. TLS protects the letter, not the envelope: it keeps the message secret and unaltered and proves the recipient, but it does not conceal that you sent a letter, or the address written on the outside.
A certificate for your own site
The moment this stops being abstract is when you publish something of your own. A site served over plain http:// gives visitors no privacy and no proof of identity, and browsers now mark it plainly as not secure. To earn the padlock, a site needs a certificate: a name-to-key binding for its domain, signed by a certificate authority that browsers already trust, installed on the server so it can be presented during the handshake.
Certificates expire on purpose, so obtaining one is not a one-time task. It has to be renewed before its validity period ends, which is why automated renewal is now the norm rather than a calendar reminder. A lapsed certificate does not degrade quietly; the day it expires, every visitor starts getting the full-page warning, because the client's date check fails exactly as designed.
Knowing the mechanism also makes certificate errors readable instead of frightening. A warning about an expired certificate, a name that does not match, or an issuer the browser does not recognize is not random breakage: it is one of the client-side checks failing, telling you precisely which promise the connection could not keep. That is the difference between clicking through blindly and knowing whether it is safe to.