Follow an HTTP request and response, explain what TLS adds, and inspect a website's certificate in your browser.
Why it matters
Almost every application talks over HTTP, and almost all of that traffic is protected by TLS (HTTP over TLS is HTTPS). APIs, cloud consoles, database admin panels and model-serving endpoints all use it. Reading status codes and headers is a daily debugging skill, and understanding certificates helps you fix "your connection is not private" errors and spot attacks.
HTTP: requests and responses
HTTP is a text-based request/response protocol. The client sends a request:
GET /docs/start HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
The server sends a response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Content-Length: 5120
<!doctype html> ...
Methods say what the client wants: GET reads, POST creates or submits, PUT/PATCH update, DELETE removes.
Status codes are grouped by the first digit:
| Range | Meaning | Common examples |
|---|---|---|
| 2xx | success | 200 OK, 201 Created, 204 No Content |
| 3xx | redirect or cached | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
HTTP is stateless: each request stands alone. Logins work by the server setting a cookie that the browser sends back on later requests.
Versions: HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many over one TCP connection, and HTTP/3 runs over QUIC on UDP.
The problem TLS solves
Plain HTTP crosses many networks (your Wi-Fi, your ISP, other carriers). Anyone on the path could read passwords or change the page. TLS provides three things:
- Confidentiality: traffic is encrypted.
- Integrity: tampering is detected.
- Authentication: you are talking to the real
example.com, proven by a certificate.
Certificates and trust
A certificate binds a public key to one or more names (listed in the Subject Alternative Names). It is signed by a certificate authority (CA). Your operating system and browser ship with a list of trusted root CAs. Sites usually send a chain: their leaf certificate plus an intermediate certificate, which was signed by a root you already trust.
The browser checks that:
- the chain leads to a trusted root,
- the name you typed matches the certificate,
- today is within the validity dates,
- the certificate has not been revoked.
Free CAs such as Let's Encrypt issue certificates valid for 90 days or less and renew them automatically, so expiry problems are usually an automation failure.
The TLS 1.3 handshake, simplified
- ClientHello: the browser lists supported cipher suites and sends a key share.
- ServerHello: the server picks a cipher suite, sends its key share, its certificate and a signature proving it holds the private key.
- Both sides compute the same session keys from the key shares (a Diffie-Hellman exchange). From here on, everything is encrypted with fast symmetric encryption.
- The HTTP request travels inside the encrypted tunnel.
TLS 1.3 needs one round trip before data flows; TLS 1.0 and 1.1 are obsolete and disabled by modern browsers.
What an observer still sees
With HTTPS, someone on your network cannot see page contents, paths, cookies or form data. They can still see your IP address, the server's IP address, timing and volume, and usually the site's name (from DNS and the Server Name Indication field), unless encrypted DNS and Encrypted Client Hello are in use.
Worked example: reading a failure
A user reports NET::ERR_CERT_DATE_INVALID. You open the certificate and see it expired yesterday: the renewal job failed. A different error, ERR_CERT_COMMON_NAME_INVALID, would mean the certificate does not list the name used, for example a certificate for example.com served on api.example.com.
Common mistakes
- Treating the padlock as "safe site". It means the connection is encrypted to that name; phishing sites have valid certificates too.
- Clicking through certificate warnings on public networks.
- Mixing HTTP resources into an HTTPS page (mixed content), which browsers block.
- Reading 401 and 403 as the same. 401: not authenticated (log in); 403: authenticated but not allowed.
Quick recap
- HTTP: methods, status codes, headers; stateless, with cookies for sessions.
- TLS adds encryption, integrity and server authentication.
- Certificates chain up to a trusted root CA and must match the name and dates.
Try it
Open the Do tab to inspect a certificate and real HTTP traffic in your browser.