Application-Layer Symptoms: HTTP & TLS-Specific Failures

Network Troubleshooting

Chapter 9 · Application-Layer Symptoms: HTTP & TLS-Specific Failures

This is the top rung of Chapter 2's ladder. Chapter 8 gave a first taste of a TLS-specific failure; this chapter reads TLS handshake problems and HTTP status codes properly, as real diagnostic signal rather than just "it errored." It's also worth naming up front what's different about this rung compared to every one before it: for the very first time, getting a response — any response, including an error — is itself good news about everything below it.

An HTTP error is proof the network worked

Receiving an HTTP status code back at all — even a 500 — is only possible once DNS resolved (Chapter 4), the network path worked (Chapter 5), the port accepted a connection (Chapter 6), and, for HTTPS, the TLS handshake completed successfully (this chapter). None of that could have happened if any lower rung had actually failed. A user reporting "I got an error page" is, whether they realize it or not, handing you confirmation that the first four rungs of the ladder are already fine — the remaining question is narrower than it sounds.

Reading a TLS Handshake Failure

Chapter 8 covered one TLS failure — an untrusted certificate issuer, caused by a transparent proxy's own re-issued certificate. That's one of several distinct TLS failure signatures worth telling apart, since each points at a genuinely different fix:

Failure	What it means
Unable to get local issuer certificate	The client doesn't trust the certificate's issuing authority — Chapter 8's transparent-proxy scenario is one cause; a genuinely misconfigured server chain is another
Certificate has expired	The certificate's own validity window has passed — an operational/renewal problem, not a trust or network issue
Hostname mismatch	The certificate presented doesn't cover the name being requested — common behind a load balancer or reverse proxy serving the wrong certificate for a given hostname (SNI)
Handshake failure / no shared cipher	The client and server couldn't agree on a TLS version or cipher — often an old client library that doesn't support a server's minimum required TLS version

This site's own HTTPS/TLS Fundamentals (https1) course covers the handshake mechanics and certificate chain of trust behind each of these in full — this chapter focuses specifically on recognizing which one you're looking at from a failure message.

HTTP Status Codes as Diagnostic Signal

Range	What it tells you
2xx	Success — the request was received and handled as expected
3xx	A redirect — worth following explicitly (`curl -L`) rather than assuming; a redirect loop or an unexpected destination is itself a real, diagnosable symptom
4xx	Reported as a client-side problem, but not always literally the client's fault — a 401/403 can come from the application's own authorization logic, or from a WAF or reverse proxy blocking the request before it ever reaches the application
5xx	A server-side failure — the request was received and something failed while handling it; which specific 5xx code narrows down where in the server-side chain it happened

A 403 doesn't tell you, on its own, who blocked you

An authorization failure and a security block can look identical from the client side. The application itself might be correctly enforcing a permissions rule, or a Web Application Firewall (WAF) — itself a specialized, application-aware relative of Chapter 7's own firewalls — might be rejecting the request based on its IP, pattern, or rate before it ever reaches the actual application. Telling the two apart from outside usually needs the same thing Chapter 7 needed for a plain network-layer firewall: server-side or WAF logs, not just the client's own response.

The 5xx Family, Specifically

These four get conflated constantly, but each says something genuinely different about where the failure happened:

Code	What it specifically means
500 Internal Server Error	A generic failure inside the application itself — no more specific information is being given
502 Bad Gateway	A reverse proxy or gateway received an invalid or malformed response from the backend it forwarded the request to — the proxy itself is fine; its upstream isn't
503 Service Unavailable	The server is deliberately not handling requests right now — overloaded, or in maintenance mode; often paired with a `Retry-After` header
504 Gateway Timeout	A reverse proxy or gateway's upstream never responded within the allowed time — distinct from 502, where the upstream did respond, just invalidly

Reading curl -v's Full Timeline

Put together, one verbose curl request shows every phase this course has built toward, in order:

$ curl -v https://app.example.com/api/status
*   Trying 203.0.113.42:443...
* Connected to app.example.com (203.0.113.42) port 443   # Chapter 6: port confirmed open
* TLS handshake, Client Hello
* TLS handshake, Server Hello, Finished              # This chapter: TLS confirmed
> GET /api/status HTTP/1.1
> Host: app.example.com
<
< HTTP/1.1 502 Bad Gateway                              # This chapter: application-layer result

Every line above the status code is confirmation, not failure — the connection, the TLS handshake, and the request itself all completed. The 502 specifically says the reverse proxy fronting this app received a response from its own backend, and that response was invalid — narrowing the problem to the backend service itself, or the connection between the proxy and that backend, rather than anything this course's earlier chapters cover.

From here, this becomes log1's territory

Once a genuine application-layer failure is confirmed — as opposed to a network, DNS, port, or TLS problem — actually diagnosing why the backend returned an invalid response belongs to this site's own Logging & Log Analysis (log1) course, whose Chapters 6 and 7 build exactly this kind of walkthrough in depth. This course's ladder exists to get you confidently to that handoff point — confirming which rung actually failed — not to replace the log-reading skill needed once it has.

Hands-On Exercises

Exercise 1

A user reports "I got a 500 error page." Explain why this chapter treats that report as good evidence, not just bad news, and specifically what it already confirms.

📄 View solution

Exercise 2

Explain the specific difference between a 502 Bad Gateway and a 504 Gateway Timeout, and what each one tells you about where in the request chain the failure happened.

📄 View solution

Exercise 3

A request returns a 403 Forbidden. Explain why this chapter says that alone doesn't tell you whether the application or a WAF produced it, and what Chapter 7 concept this connects to.

📄 View solution

Chapter 9 Quick Reference

Any HTTP status code, even an error, proves DNS, network reachability, port, and TLS (if applicable) all already worked
TLS failures: untrusted issuer (Chapter 8), expired certificate, hostname mismatch, no shared cipher/version — each points at a different fix; see https1 for the full mechanics
2xx = success; 3xx = redirect, worth following explicitly; 4xx = reported client-side, but a 401/403 could be the app or a WAF; 5xx = server-side
500 = generic app failure; 502 = proxy got an invalid response from its backend; 503 = deliberately unavailable; 504 = the backend never responded in time
A 403 doesn't reveal, on its own, whether the application or a WAF produced it — same ambiguity as Chapter 7's plain firewall block
Once the ladder confirms a genuine application-layer failure, actually diagnosing it becomes Logging & Log Analysis (log1) territory
Next chapter: Capstone: Triaging Three Real Connectivity Tickets