HTTP and TLS¶

By Sameer Alam · Updated 20 October 2026

What You'll Learn¶

• The structure of an HTTP request and response, and what status codes really tell you
• The headers that matter for operations: caching, proxies, and host routing
• What HTTP/2 and HTTP/3 change
• How TLS protects traffic, how certificates are validated, and how to debug TLS failures

Anatomy of an HTTP Request¶

curl -v https://api.example.com/orders/42

> GET /orders/42 HTTP/2
> Host: api.example.com
> User-Agent: curl/8.9.1
> Accept: */*
>
< HTTP/2 200
< content-type: application/json
< cache-control: no-store
< x-request-id: 7f1c2a9e
<
{"id": 42, "status": "shipped"}

The Host header tells the server which site you want. One IP address can serve many hostnames — reverse proxies route on it.

Methods¶

Idempotency matters for retries: load balancers, clients, and service meshes can safely retry idempotent requests, but retrying a POST can create a duplicate order.

Status Codes¶

For SLOs, 5xx responses are usually counted as errors and most 4xx are not — a user mistyping a URL isn't an outage. A sudden spike in 401, 403, or 429 still deserves an alert. Load Balancers explains what 502, 503, and 504 mean when a proxy is involved.

Headers That Matter in Operations¶

HTTP/1.1, HTTP/2, and HTTP/3¶

HTTP/3 needs UDP port 443 open. If a firewall blocks it, clients fall back to HTTP/2 over TCP — slower to connect but it works.

gRPC runs over HTTP/2, so any proxy in front of a gRPC service must support HTTP/2 end to end.

Timing a Request¶

curl -s -o /dev/null -w '
dns:        %{time_namelookup}s
connect:    %{time_connect}s
tls:        %{time_appconnect}s
first byte: %{time_starttransfer}s
total:      %{time_total}s
status:     %{http_code}
' https://api.example.com/health

Each value is cumulative from the start. A large jump between tls and first byte means the server is slow to respond; a large dns value points at resolution; a large connect points at network latency or a SYN queue problem.

TLS¶

TLS gives three guarantees: confidentiality (encryption), integrity (tampering is detected), and authentication (you're talking to the real api.example.com).

The TLS 1.3 handshake¶

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (SNI: api.example.com, key share, supported ciphers)
    S-->>C: ServerHello (key share) + certificate + signature + Finished
    Note over C: Verify the certificate chain and hostname
    C->>S: Finished
    Note over C,S: Encrypted application data (one round trip total)

• SNI (server name indication) sends the hostname in the first message, so one IP can serve certificates for many domains.
• TLS 1.3 completes in one round trip. TLS 1.0 and 1.1 are obsolete; TLS 1.2 is still widely supported.
• Current browsers, OpenSSL 3.5+, and major CDNs negotiate a hybrid post-quantum key exchange (X25519MLKEM768) by default, protecting today's traffic against future quantum decryption. Its larger ClientHello spans more than one packet, which occasionally breaks old firewalls and TLS-inspecting middleboxes: if new clients fail to connect through one specific network path while older clients work, suspect that.

How a certificate is validated¶

flowchart BT
  Leaf["Leaf certificate<br/>api.example.com"] -->|"signed by"| Int["Intermediate CA"]
  Int -->|"signed by"| Root["Root CA<br/>(in the client's trust store)"]

The client checks that:

1. The chain leads to a root CA it already trusts.
2. The hostname matches a Subject Alternative Name in the leaf certificate (the old Common Name field is ignored by modern clients).
3. The current time is within the certificate's validity period.
4. The certificate hasn't been revoked.

The server must send the intermediate certificates. Browsers sometimes fetch missing intermediates on their own, which hides the problem — while curl, Java, and Python clients fail.

Inspect a certificate¶

# What the server presents, including the chain
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null

# Subject, issuer, SANs, and expiry of the leaf
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName -dates

# Days until expiry, for a monitoring check
end=$(openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 )) days left

# A certificate file on disk
openssl x509 -in /etc/ssl/certs/app.pem -noout -text | less

Common TLS Errors¶

Certificate Lifetimes and Automation¶

Public TLS certificates are short-lived and getting shorter. Under the CA/Browser Forum's 2025 decision, the maximum validity of a publicly trusted certificate is falling on a fixed schedule:

Let's Encrypt certificates already last 90 days, with shorter options available. The practical consequence: a certificate renewed by hand once a year is no longer possible, and even a quarterly manual renewal will soon miss. Automate renewal everywhere, and alert on expiry anyway. Use:

• ACME clients such as Certbot for servers
• cert-manager in Kubernetes
• Managed certificates from cloud load balancers (AWS Certificate Manager, Google-managed certificates), which renew automatically

Paste a certificate's dates to check it, and see how much manual renewal will cost under each phase of the schedule:

Mutual TLS¶

In mTLS, the client also presents a certificate and the server verifies it. It's used for service-to-service authentication inside meshes (Istio, Linkerd) and for machine clients of sensitive APIs. The same chain and expiry rules apply in both directions.

What Most Engineers Miss¶

• Let's Encrypt no longer emails you before expiry. Expiration reminder emails ended on 4 June 2025. If those emails were your monitoring, you have none.
• OCSP is going away. Let's Encrypt removed OCSP URLs from new certificates in May 2025 and shut its OCSP service down on 6 August 2025, publishing revocation through CRLs only. Software that insists on OCSP stapling for those certificates needs updating.
• Domain validation gets short-lived too. A CA may reuse a successful domain check for 398 days today, falling to 10 days in 2029. Renewal will mean proving control of the domain again almost every time, which only works with ACME HTTP-01 or DNS-01 challenges automated end to end.
• Let's Encrypt is shortening its own default. It already offers 45-day (tlsserver) and six-day (shortlived) profiles; the default drops from 90 to 64 days on 10 February 2027 and to 45 days on 16 February 2028.
• The client's trust store is part of TLS. A container built from a three-year-old base image carries three-year-old root certificates. Update ca-certificates in every image build.
• HTTP/2 features are an attack surface. Stream cancellation, a normal HTTP/2 feature, powered the largest DDoS attacks ever recorded in 2023, and a variant in 2025. Proxies and app servers that speak HTTP/2 need prompt patching.

Common Mistakes¶

• Serving only the leaf certificate, so non-browser clients fail with "unable to get local issuer certificate".
• Manually renewed certificates with no expiry monitoring — still one of the most common causes of full outages.
• Retrying non-idempotent POST requests at the load balancer or client, creating duplicates.
• Counting every 4xx as an error in SLOs, or ignoring a spike in 401s after a deploy.
• Using curl -k in scripts and health checks, hiding real certificate problems.
• Terminating TLS at a load balancer and sending plaintext across networks you don't control.

Check Yourself¶

Interview Questions¶

• What's the difference between 502, 503, and 504?
• Which HTTP methods are idempotent, and why does that matter for retries?
• Walk through a TLS 1.3 handshake. What is SNI for?
• A Python client fails with "unable to get local issuer certificate", but the site works in a browser. Why?
• How would you make sure certificates never expire unnoticed across hundreds of services?

Next¶

Continue to Load Balancers and Reverse Proxies.