How HTTPS Works: TLS, Certificates & the Padlock

The s in HTTPS stands for secure, and for most people that is where the understanding stops. The padlock appears, the site feels safe, and the details stay hidden. Those details decide whether your password reaches the right server, whether anyone on the network can read it, and whether the page you loaded is the page the server actually sent. It is worth knowing what the lock really certifies.

HTTPS is HTTP running inside a protected tunnel. The tunnel is TLS, the Transport Layer Security protocol. HTTP is the same request-and-response language it always was. TLS wraps that conversation so it stays private and unaltered, and so your browser can confirm it is talking to the real server. Nothing about the web pages changes. What changes is the channel underneath them.

The three jobs TLS does

TLS solves three separate problems in one handshake. Keeping them distinct is the key to understanding what HTTPS can and cannot promise.

Property	Question it answers	How TLS provides it
Confidentiality	Can anyone on the path read this	Symmetric encryption of every byte after the handshake
Integrity	Was anything changed in transit	Authenticated encryption that rejects tampered data
Authentication	Am I really talking to this domain	The server's certificate, signed by a trusted authority

Confidentiality is the part everyone knows. Integrity is quieter and just as important, because encryption without tamper detection would let an attacker flip bits without reading them. Authentication is the part the padlock is really about, and the part most often misread.

What a certificate actually is

A TLS certificate is a small signed document. At its heart it says: this public key belongs to this domain name, and it is valid until this date. It carries the domain, the public key, the expiry, the issuing authority, and a digital signature over all of it.

Your browser does not trust the certificate because the site presented it. Anyone can generate a certificate claiming to be any domain. Your browser trusts it because it was signed by a certificate authority (CA) that your browser or operating system already trusts. Those trusted CAs ship in a root store on your device. A valid chain runs from the server's certificate, up through one or more intermediate CA certificates, to a root the device already trusts.

There are three grades of certificate, and the difference matters:

• Domain Validation (DV). The CA checked only that the applicant controls the domain, usually by a DNS record or a file on the server. This is the vast majority of certificates and can be issued in seconds for free.
• Organization Validation (OV). The CA also checked that a named organization exists and controls the domain.
• Extended Validation (EV). A stricter identity check on the organization. Browsers no longer give EV any special visual treatment, so users rarely see the difference.

How the handshake starts a session

Before any HTTP flows, TLS runs a handshake. In TLS 1.3, the current version defined in RFC 8446, it takes a single round trip. The steps in plain terms:

1. The browser says hello and offers the cipher options it supports, along with a key share.
2. The server replies with its choice, its certificate, and its own key share.
3. Both sides combine their key shares to derive the same secret without ever sending it across the wire. This is a Diffie-Hellman key exchange.
4. The browser validates the certificate: correct domain, unexpired, chains to a trusted root, not revoked.
5. Both sides switch to fast symmetric encryption using the shared secret, and the HTTP conversation begins inside the tunnel.

The clever part is step three. The encryption key is never transmitted. Each side contributes half and the shared value emerges from the math, so a passive eavesdropper who recorded the whole exchange still cannot derive it. Modern TLS also gives each session a fresh key, so recording traffic today and stealing the server key later still does not decrypt the past. That property is called forward secrecy.

Validation in step four has more to it than checking the domain and date. The browser also needs to know the certificate has not been revoked, meaning the CA has not withdrawn it early because the private key was stolen or the certificate was mis-issued. Revocation is handled through published lists and status responses, and browsers increasingly rely on short-lived certificates so a compromised one expires on its own before revocation even matters. If any check fails, the browser should stop, not warn and continue. A confident error page is doing its job; a click-through past a certificate error throws the whole guarantee away.

One more piece the handshake sets up is the Server Name Indication, or SNI. Because one server address can host many domains, the browser has to say which domain it wants so the server can present the right certificate. In standard TLS the SNI travels early and in the clear, which is why the destination domain leaks even when everything else is encrypted. Encrypted Client Hello is the newer effort to close that last gap, and it depends on encrypted DNS to fetch the keys it needs.

What HTTPS protects, and what it does not

This is where most misunderstandings live. HTTPS has a precise scope.

It protects:

• The contents of requests and responses from anyone watching the network, including on shared Wi-Fi, at your ISP, or anywhere along the path.
• The integrity of that data, so an attacker in the middle cannot inject or rewrite content undetected.
• The identity of the server, confirming the certificate is valid for the exact domain in the address bar.

It does not protect:

• Against a malicious or fraudulent site. A scam site with valid HTTPS is still a scam site.
• A server that has already been compromised. HTTPS secures the path to the server, not what happens on it.
• Your password once you type it into a phishing page. Encryption faithfully delivers your credentials to the attacker.
• The destination itself. Even with HTTPS, the domain you visit leaks through the TLS SNI field and through DNS lookups, unless you also encrypt those. See DNS over HTTPS vs DNS over TLS.

That last point surprises people. HTTPS hides the page and the path, /account/settings, but not the fact that you connected to a given domain. Encrypted DNS and encrypted SNI narrow that gap.

The downgrade problem

An HTTPS site is only protected if the browser actually uses HTTPS. The first request a user makes by typing a bare domain often starts as plain HTTP, and the server redirects to HTTPS. An attacker positioned on the network can intercept that first plain request and quietly keep the whole session on HTTP, stripping the encryption while the user sees a normal-looking page. This is SSL stripping, covered in SSL Stripping Explained.

HSTS closes this. When a server sends the HTTP Strict Transport Security header, browsers remember to use HTTPS for that domain for a set period, refusing plain HTTP entirely. Preloading the domain into browsers extends this to the very first visit. See HSTS Explained.

How to use HTTPS well

For anyone running a site or judging one:

1. Force HTTPS everywhere and set HSTS. Redirect all HTTP to HTTPS and send the Strict-Transport-Security header. Consider the preload list for domains you fully control.
2. Use TLS 1.2 or 1.3 only. Disable older protocol versions and weak ciphers. NIST SP 800-52 Rev. 2 gives the current baseline.
3. Automate certificate renewal. Expired certificates are a common, avoidable outage. Short-lived automated certificates remove the manual step.
4. Read the address bar, not the lock. As a user, verify the exact domain. The lock tells you the channel is encrypted, and nothing about who is on the other end.
5. Track your certificates. Certificate Transparency logs record every certificate issued for your domains, which helps you spot mis-issuance early.

A worked example: loading a page over HTTPS

Following a single page load makes the moving parts concrete. Suppose someone types example.test into the address bar.

First the browser resolves the name. It performs a DNS lookup to turn example.test into an IP address. In a standard setup this lookup travels in the clear, which is the first place the destination domain leaks even before any HTTPS begins. With encrypted DNS, the lookup itself is protected, which narrows that leak.

Next the browser opens a TCP connection to that IP on port 443, the standard HTTPS port. It then starts the TLS handshake. It sends a hello offering its supported cipher options, a key share, and, in the common case, the Server Name Indication naming example.test so a server hosting many sites knows which certificate to present. The server replies with its choice, its certificate chain, and its own key share. Both sides derive the same secret from their key shares without transmitting it, and the browser validates the certificate: it confirms the certificate covers example.test, that it has not expired, that it chains to a root the device trusts, and that it has not been revoked.

Only now does any HTTP flow. The browser sends its HTTP request, GET / with headers, inside the encrypted tunnel. The server sends the HTML response back through the same tunnel. Anyone watching the network saw a DNS lookup, a connection to an IP on port 443, the SNI in the clear, and then an opaque stream of encrypted bytes. They did not see the path requested, the response, any cookies, or any submitted data. The browser then makes further encrypted requests for the page's images, scripts, and styles, and the padlock appears once the main document loaded over a valid HTTPS connection.

What the browser checks in a certificate

Certificate validation is more than confirming a name and a date, and each check closes a specific gap.

The browser checks the signature chain. The server's leaf certificate must be signed by an intermediate CA, which must be signed by a root in the device's trust store. A break anywhere in that chain, or a root the device does not trust, fails validation. It checks the name. The certificate must cover the exact domain in the address bar, through either the common name or, in practice, the subject alternative names. A certificate for example.test does not validate for login.example.test unless that name is listed. It checks the validity dates. A certificate presented before it becomes valid or after it expires fails. It checks revocation. The CA may have withdrawn a certificate early because its private key was stolen or it was mis-issued, and the browser consults revocation information to catch that.

When any of these fails, the correct behavior is to stop, not to warn and let the user continue. A certificate error page is the guarantee doing its job. Clicking through it discards the authentication that TLS worked to establish.

Check	What it confirms	Failure meaning
Signature chain	A trusted CA vouched for this certificate	Untrusted or forged certificate
Domain name	The certificate matches the address bar	Certificate is for a different site
Validity dates	The certificate is currently in its valid window	Expired or not yet valid
Revocation status	The CA has not withdrawn the certificate early	Possibly compromised or mis-issued

Detection signals and healthy indicators

Whether you run a site or assess one, several observable signals tell you HTTPS is working as intended, and several point to trouble.

On a healthy deployment, every HTTP request redirects to HTTPS, the response carries a Strict-Transport-Security header, the negotiated protocol is TLS 1.2 or 1.3, and the certificate chain is complete and current. Certificate Transparency logs, which publicly record every certificate issued for a domain, show only certificates you expected. Monitoring those logs is one of the most practical detection tools available, because a certificate issued for your domain that you did not request is a direct signal of mis-issuance or an attempt to impersonate you.

Signs of trouble include a site served over plain HTTP with no redirect, a missing or short-lived HSTS policy on a domain that should have one, negotiated protocol versions below TLS 1.2, an incomplete chain that some clients reject, and certificate names that do not match the domain. For a user, the signal is the address bar: a domain that is a lookalike of a real one, or a certificate error clicked through, are the moments where the guarantees quietly fall apart.

How HTTPS became the default

For most of the web's history, HTTPS was the exception, reserved for login pages and checkout flows, while everything else traveled as readable HTTP. Several forces changed that. Free automated certificate authorities removed the cost and manual effort that once made certificates a chore, so any site could get and renew one without paying or filing paperwork. Browsers began marking plain HTTP pages as not secure, which turned the absence of HTTPS into a visible warning. Search and performance incentives lined up behind encryption, and modern protocol versions made the handshake fast enough that the old performance argument against HTTPS disappeared.

The result is that HTTPS is now the assumed default rather than a feature to opt into. New web capabilities are increasingly gated behind it, so a site on plain HTTP loses access to parts of the platform. For anyone building today, the practical stance is that every site uses HTTPS everywhere, certificates renew automatically, and plain HTTP exists only as a redirect to its secure equivalent.

Common misconceptions

A few beliefs about HTTPS cause real harm.

The first is that the padlock means the site is safe. The padlock means the connection is encrypted and the certificate matches the address bar. A scam site can obtain a valid Domain Validation certificate in seconds and show a padlock, so the lock says nothing about the honesty of the people running the site.

The second is that HTTPS hides which sites you visit. It hides the path and the page contents, and the destination domain still leaks through the DNS lookup and, in the common case, the SNI field in the handshake. Encrypted DNS and Encrypted Client Hello narrow that gap, and without them the domain is visible to a network observer.

The third is that a certificate error is a minor inconvenience to click past. A certificate error means one of the checks that authenticate the server failed. Clicking through it throws away the authentication guarantee entirely, which is exactly what an attacker performing interception needs the user to do.

The fourth is that HTTPS protects the server. It protects the channel to the server and proves the server's identity. A server that is already compromised will serve malicious content over a perfectly valid HTTPS connection, because the encryption faithfully delivers whatever the server sends.

Frequently asked questions

Does HTTPS mean a website is trustworthy? No. HTTPS means the connection is encrypted and the site presented a valid certificate for the domain in the address bar. Most certificates are Domain Validation, which prove only that the holder controls the domain. A phishing site can obtain one and display a padlock, so trustworthiness is a separate judgment from whether the connection is secure.

What is the difference between HTTP and HTTPS? HTTP is the request-and-response language browsers and servers speak. HTTPS is that same HTTP carried inside a TLS-encrypted tunnel. The web content and the requests are identical, and the difference is the protected channel underneath, which provides confidentiality, integrity, and proof of the server's identity.

Can someone still see which sites I visit over HTTPS? Often yes. HTTPS hides the specific pages and the contents of your requests, and the destination domain typically leaks through the DNS lookup and the Server Name Indication field in the TLS handshake, both of which are commonly sent in the clear. Encrypted DNS and Encrypted Client Hello are the technologies that close those remaining gaps.

Why do browsers no longer show a company name for EV certificates? Extended Validation certificates involve a stricter identity check on the organization, and browsers found that the special visual treatment did not meaningfully help users make safer decisions, so they removed it. Today all certificate grades look the same in the address bar, which is why reading the exact domain matters more than looking for any badge.

What does HSTS do and why does it matter? HTTP Strict Transport Security is a header that tells a browser to always use HTTPS for a domain for a set period, refusing plain HTTP entirely. It closes the window that SSL stripping relies on, where an attacker intercepts an initial plain HTTP request and keeps the session unencrypted. Preloading the domain into browsers extends this protection to the very first visit.

Is a self-signed certificate ever acceptable? For internal testing or systems where you control both ends and can distribute your own trust anchor, a self-signed or private CA certificate can be appropriate. For a public site, it is not, because visitors' browsers have no reason to trust it and will show an error. The point of the public CA system is that a browser can trust a site it has never seen before.

What happens if a certificate expires? The browser fails validation and shows a certificate error, which stops the connection and alarms users. Expired certificates are a common and entirely avoidable outage. Automating renewal, and using short-lived certificates that are reissued frequently, removes the manual step where an expiry usually slips through.

HTTPS is one of the quiet successes of the modern web. It turned open, readable traffic into private, verified channels by default. Understand it for what it is, a secure pipe with a proof of domain identity attached, and you will stop reading the padlock as a promise it was never designed to make. Attackers count on that misreading, and you can see how they exploit fetched content and file-based lures in our malicious file formats reference.

Related guides

• How the TLS Handshake Works
• What Is PKI
• HSTS Explained
• SSL Stripping Explained