How HTTPS works, in plain words

HTTPS is ordinary HTTP - the same requests, the same pages - sent through an encrypted tunnel called TLS. Before a single byte of the page moves, your browser and the server agree on a secret key that nobody watching the network can work out, and the server proves with a certificate that it really is the site whose name you typed. After that, anyone between you and the server sees that you connected to a particular address and roughly how much data went each way. They do not see the pages, the forms, the passwords or the cookies, and they cannot change any of it without the connection breaking.

That is the whole idea. The rest of this post is how each part works, what the padlock does and does not promise, and why a site with nothing to hide still needs it.

HTTP vs HTTPS: what actually changes#

Plain HTTP is text sent in the open. A request for a login page looks, on the wire, exactly like what the browser wrote:

POST /login HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencodedemail=anna%40example.com&password=herring-barrel-42

Every device that carries that packet - the cafe's router, the hotel's network box, the internet provider, any machine between them - can read it, keep it, or rewrite it. Rewriting is not hypothetical: providers and public hotspots have injected adverts, tracking scripts and "you are near your data cap" banners into plain HTTP pages for years.

HTTPS changes the transport and nothing above it:

The application does not change. The same server code, the same HTML, the same cookies - TLS wraps the connection, and HTTP runs inside it unaware. That is also why "SSL" and "TLS" are used interchangeably: SSL was the original protocol from the 1990s, TLS is its successor, and every version of SSL has been formally retired as broken. What is called an "SSL certificate" today is used exclusively with TLS, and the current versions are TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 were deprecated in 2021 and modern browsers refuse them.

The two kinds of encryption it uses#

HTTPS combines two families of cryptography, because each is good at what the other is bad at.

Symmetric encryption uses one key for both locking and unlocking. It is fast enough to encrypt video in real time on a phone. Its weakness is obvious: both sides need the same key, and you cannot simply send the key across the network that you are trying to protect. The ciphers used in practice are AES in GCM mode and ChaCha20-Poly1305; both also detect any change to the data, so tampering is caught, not just eavesdropping.

Asymmetric (public-key) cryptography uses a pair of keys. What one key does, only the other can verify or undo. One half is public and handed to anyone; the other is private and never leaves the server. This is slow, but it solves the two hard problems: two strangers can agree on a shared secret over an open line, and one of them can prove who it is without revealing anything that could be reused.

So HTTPS uses the slow, clever kind once at the start, to agree on a key and check identity, and the fast kind for everything after. The agreement step is a key exchange - in practice a variant of Diffie-Hellman over elliptic curves, such as X25519. Each side picks a random secret, sends a value derived from it, and both sides combine what they received with their own secret to arrive at the same number. An observer who saw both values in transit still cannot compute it.

A detail worth knowing: modern TLS throws those exchange secrets away after each connection. This is called forward secrecy, and it means that if the server's private key is stolen next year, traffic recorded today still cannot be decrypted. TLS 1.3 makes it mandatory; older setups that encrypted the session key directly with the server's certificate key did not have it.

Certificates and certificate authorities#

Encryption alone is not enough. If an attacker sits between you and the server, they can run a perfectly encrypted connection with you and another with the real server, reading everything in the middle. The key exchange would succeed with the wrong party. What stops that is the certificate.

A certificate is a small file that binds a public key to one or more names. Its important fields:

• Subject alternative names - the hostnames it is valid for, such as example.com and www.example.com, or a wildcard like *.example.com that covers one level of subdomain.
• Public key - the public half of the key pair whose private half sits on the server.
• Validity - a "not before" and "not after" date. Outside that window the certificate is rejected.
• Issuer and signature - which authority vouches for this binding, and its digital signature over all of the above.

The authority is the point. A certificate authority (CA) is an organisation whose own public keys ship inside your operating system or browser, in a list called a root store. Mozilla, Apple, Microsoft and Google each maintain one and audit the CAs in it. When a CA signs a certificate, it is stating that it checked the requester controls the name. For the free certificates most sites use, that check is automated: the CA asks the requester to publish a token on the domain and fetches it - HTTPS and Let's Encrypt explained covers exactly how that challenge runs.

Roots are kept offline and rarely used, so the CA signs your certificate with an intermediate key, and the intermediate is signed by the root. The server sends its own certificate plus the intermediate; the browser already has the root. That is the chain:

The browser checks each signature upwards until it reaches a root it already trusts. If any link is missing, expired, or signed by something unknown, the connection is refused with a warning. A server that sends only its own certificate and forgets the intermediate is the classic misconfiguration, and it is maddening because it works in some browsers - those that happen to have cached the intermediate from another site - and fails in others.

Every public certificate is also logged in Certificate Transparency logs, public append-only records that anyone can search. Browsers require proof that a certificate was logged. The result is that a CA cannot quietly issue a certificate for your domain to somebody else without leaving a trace you can find.

The TLS handshake, step by step#

When you open https://example.com, this is what happens before the first byte of HTML arrives. The description is TLS 1.3, which almost every current browser and server negotiates; TLS 1.2 follows the same logic with one extra round trip.

1. TCP connection. The browser resolves the name through DNS and opens a connection to port 443 on that address. (DNS records explained covers the lookup.)
2. ClientHello. The browser sends the TLS versions and ciphers it supports, a random value, its half of the key exchange (a "key share"), and two extensions that matter: SNI, the hostname it wants, so a server hosting many sites knows which certificate to present; and ALPN, the protocols it can speak, such as h2 for HTTP/2.
3. ServerHello. The server picks a version and cipher and sends its own key share. At this moment both sides can compute the same secret, and everything from here on is encrypted.
4. Certificate. The server sends its certificate and the intermediate chain.
5. CertificateVerify. The server signs a hash of the whole conversation so far with its private key. This is the proof of identity: only the holder of the private key matching the certificate could produce that signature, and because it covers this conversation's random values, it cannot be replayed from an old one.
6. Finished. The server sends a short check value over the whole handshake, proving nothing was altered in transit.
7. Client checks. The browser verifies the chain up to a trusted root, the dates, that the name in the address bar is in the certificate's list of names, and the signature in step 5. Any failure stops the connection here, with a warning page.
8. Client Finished, then HTTP. The browser sends its own Finished message, followed immediately by the ordinary GET request - now inside encrypted records.

The whole thing costs one network round trip before the request can go out - about the same as one ping to the server. A returning visitor can resume a previous session and skip the certificate step, and TLS 1.3 even allows sending data in the very first packet on resumption ("0-RTT"), at the cost of that early data being replayable, which is why servers only accept it for requests that are safe to repeat.

You can watch a real handshake from a terminal:

# Summary: protocol, cipher, certificate subject and issuer$ openssl s_client -connect example.com:443 -servername example.com -brief < /dev/null# The same from curl, with every TLS step printed$ curl -v https://example.com -o /dev/null

The -servername flag sets SNI. Without it, a server hosting several names may hand back a default certificate for some other site, and the result looks like a broken certificate when it is really a missing flag.

HTTP/3 changes the transport underneath - it runs over QUIC on UDP port 443 instead of TCP - but the TLS 1.3 handshake is built into QUIC, and the steps above still happen.

What the padlock means, and what it does not#

The padlock, or in current Chrome a neutral settings icon in the same place, means exactly three things: the connection is encrypted, it has not been altered in transit, and the server proved it holds a valid certificate for the name in the address bar. That is a statement about the pipe, not about the people at the other end.

It does not mean:

• The site is honest. A phishing page at paypa1-secure-login.com gets a valid certificate in seconds, because the certificate only proves control of that exact name. Read the name, not the icon.
• The company is who it says. The free, common certificates are domain-validated. More expensive organisation-validated and extended-validation certificates involve checking company records, but browsers no longer display the company name in the address bar, so a visitor cannot tell them apart.
• The site is secure. HTTPS protects data in transit. It does nothing about an outdated plugin, a weak admin password or a database left open to the internet. WordPress security hardening is a better guide to that side.
• Nobody can see you visited. An observer on the network still sees the server's IP address, and usually the hostname too: SNI in the ClientHello is sent unencrypted unless both browser and server support Encrypted Client Hello, which is still rolling out, and the DNS lookup is plain text unless the device uses encrypted DNS. What they cannot see is the path, the query string, headers, cookies or content. https://example.com/account/orders?id=4411 leaks example.com; the rest stays inside the tunnel.
• Your employer or school cannot read it. Corporate networks and some antivirus products install their own root certificate on managed devices and decrypt traffic in the middle on purpose. On a device you do not control, assume this is possible. What a VPN protects and what it does not covers the overlap with VPNs.

HSTS: closing the first-request gap#

Even a site that redirects every HTTP request to HTTPS has a weak moment: the very first request. If you type example.com, the browser tries http:// first, and that plain request can be intercepted before the redirect arrives. An attacker on the same wifi can answer it themselves and keep you on HTTP indefinitely - a downgrade attack.

HSTS (HTTP Strict Transport Security) closes that gap. The server sends a header once over HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

From then on, for max-age seconds - here, a year - the browser rewrites every http:// link to that name to https:// before sending anything, and it removes the option to click through a certificate warning. The first visit is still unprotected, which is what the preload list is for: names submitted to it are hard-coded into browsers as HTTPS-only before the first visit ever happens. Some whole top-level domains, such as .dev and .app, are on that list, so every site under them must serve HTTPS from day one.

HSTS is the one HTTPS feature that can lock you out of your own site if a subdomain still needs plain HTTP, and preloading is slow to undo. Start with a short max-age, confirm everything works, then raise it. The configuration, along with the redirect and mixed-content clean-up that should come first, is in HTTPS and Let's Encrypt explained.

Why every site needs HTTPS#

"My site has no logins and no payments" is the usual argument against bothering. It no longer holds, for reasons that have nothing to do with secrecy.

• Browsers mark plain HTTP as not secure, in the address bar, on every page. Forms on HTTP pages get an extra warning when someone starts typing, and browsers increasingly try HTTPS first and warn before falling back to plain HTTP.
• Tampering affects boring pages too. An injected script on a static recipe blog runs in the visitor's browser with the same power as yours: it can redirect, mine, or show a fake login prompt.
• Modern features require it. Geolocation, camera and microphone access, service workers, push notifications, the clipboard API and HTTP/2 in browsers all need a secure context. Browsers only use HTTP/2 and HTTP/3 over TLS, so an HTTP-only site is also stuck on the older, slower protocol.
• Search engines prefer it. Google has used HTTPS as a ranking signal since 2014. It is a small signal, but it costs nothing.
• Referrer data survives. When a visitor clicks from an HTTPS page to an HTTP one, the browser strips the referrer, so HTTP sites lose part of their analytics.
• The certificate is free and renews itself. The cost argument disappeared when free, automated certificates became the norm.

On RE:NODE's app and web plans the work is reduced to one DNS record: add the hostname to the proxy slot, point an A record at the address it shows, and the certificate is issued once the name resolves and renewed automatically inside a 21-day window. The proxy terminates TLS and passes plain HTTP to your application, with the visitor's real address in X-Forwarded-For. Point a domain at your server and add SSL walks through that setup and the reasons issuance fails.

Certificate errors and what they mean#

Most HTTPS problems surface as one of a handful of browser errors. The codes differ between browsers; the causes are the same.

Expired. Either the site's renewal failed, or the visitor's device clock is wrong. A phone or PC set to a date years in the past rejects every certificate on the internet at once, which is the giveaway: if every site breaks, check the clock.

Wrong name. The certificate covers example.com but the visitor came via www.example.com, or a new subdomain was pointed at a server before a certificate was issued for it. A certificate is only valid for the names listed in it.

Unknown issuer. The server is not sending the intermediate certificate, or the certificate is self-signed. Test from a machine that has never visited the site, or use the openssl command above, which shows the chain the server actually sends.

Not secure, with a valid certificate. Mixed content: the page is HTTPS, but it loads a script, stylesheet or image over http://. Browsers block active content outright and the page half-renders. The browser console names the exact URL.

`ERR_TOO_MANY_REDIRECTS`. Usually an application behind a TLS-terminating proxy that sees plain HTTP on its own port and keeps redirecting to HTTPS. The app needs to trust the proxy's X-Forwarded-Proto header instead. What a reverse proxy does explains why.

To check how a site behaves from outside, two commands answer most questions:

# Does HTTP redirect to HTTPS, and to which host?$ curl -sI http://example.com | grep -iE "^(HTTP|location)"# Is HSTS set, and for how long?$ curl -sI https://example.com | grep -i strict-transport-security

FAQ#

Is HTTPS the same as SSL?

In everyday speech, yes. Technically HTTPS is HTTP carried over TLS, and TLS replaced SSL in 1999. Every SSL version is now retired as insecure, but the old name stuck, which is why certificates are still sold as "SSL certificates". They are used with TLS 1.2 and 1.3.

Does HTTPS slow a site down?

Not measurably on modern hardware. The handshake adds one round trip on a new connection and less on a resumed one, and the encryption itself runs in dedicated processor instructions. In practice HTTPS sites are often faster, because browsers only use HTTP/2 and HTTP/3 over TLS.

Can my internet provider see which sites I visit over HTTPS?

They can see the IP addresses you connect to and, in most cases, the hostname - from your DNS lookups and from the SNI field in the handshake. They cannot see which pages you opened, what you searched for on the site, or anything you typed. Encrypted DNS and Encrypted Client Hello narrow this further where both ends support them.

How long does a certificate last?

Free certificates from Let's Encrypt last 90 days and are renewed automatically. The industry maximum for any publicly trusted certificate has been cut repeatedly and is scheduled to keep falling over the next few years, which is why manual yearly renewal is on its way out everywhere.

Is a self-signed certificate good enough?

For encryption on a private test server, yes. For a public site, no: no browser trusts it, so every visitor gets a full-page warning, and teaching people to click through warnings defeats the identity check that makes HTTPS work.

Do I need HTTPS for a game server?

Not for the game traffic itself - Minecraft, Valheim and most games use their own protocols on their own ports, not HTTP. You need it for anything web-facing around the game: a website, a map viewer, a donation page or a panel.