Common Problems

Chapter 11

Common Problems & Attacks

Certificate errors, mixed content, downgrade/stripping, revocation, and pinning

You now understand how TLS is supposed to work. This chapter is the troubleshooting and threat catalogue: the certificate errors you'll actually hit, the attacks TLS defends against (and how), and the failure modes that still bite well-meaning admins. Each one connects back to a guarantee or mechanism from earlier chapters.

Certificate Errors — What the Browser Is Really Telling You

Most "your connection is not private" warnings come from one of a few failed checks — all from Chapters 4–5. Knowing which check failed tells you exactly what to fix:

Error	Failed check	Usual cause / fix
CERT_DATE_INVALID	validity window (Ch. 4)	cert expired — renew it (auto-renewal, Ch. 9)
COMMON_NAME_INVALID	SAN ≠ hostname (Ch. 4)	cert doesn't list the domain visited — reissue with correct SAN
AUTHORITY_INVALID	chain to trusted root (Ch. 5)	self-signed, or missing intermediate — install full chain
unable to get local issuer	incomplete chain (Ch. 5)	server sent leaf only — use fullchain.pem (Ch. 10)

Mixed Content — HTTPS Page, HTTP Resources

A page served over HTTPS that pulls in sub-resources over plain HTTP is mixed content. It quietly defeats the page's security: those HTTP requests are unencrypted and tamperable, so the "secure" page isn't actually secure end-to-end.

<!-- page loaded over https://example.com but... -->
<script src="http://example.com/app.js"></script>   # insecure! tamperable
<script src="https://example.com/app.js"></script>  # or just //example.com/app.js

Browsers split this into two severities: active mixed content (scripts, stylesheets, iframes — things that can alter the page) is blocked outright, while passive mixed content (images, media) triggers a downgraded padlock warning. The fix is to load every resource over HTTPS (use https:// or protocol-relative URLs), and a Content-Security-Policy: upgrade-insecure-requests header can auto-rewrite stragglers.

SSL Stripping & Downgrade Attacks

Two related man-in-the-middle attacks, both already half-covered in earlier chapters — here's how they're defeated:

SSL stripping — the attacker intercepts the victim's initial plaintext request and keeps them on HTTP, proxying to the real HTTPS site so the user never sees a warning. Defeated by HSTS (Chapter 10): the browser refuses HTTP for the domain, so there's no plaintext request to strip. Preload closes even the first-visit gap.
Protocol/cipher downgrade — the attacker tampers with the cleartext ClientHello to force a weak protocol or cipher. Defeated by the Finished hash (Chapter 6), which covers the whole transcript, plus TLS 1.3 simply removing the weak options to downgrade to (Chapter 7).

Notice the pattern: every attack maps to a defence you've already learned

This is the satisfying part of reaching Chapter 11 — you're not learning new magic, you're seeing the mechanisms pay off. Stripping → HSTS. Downgrade → Finished + 1.3's removed options. Eavesdropping → encryption. Tampering → AEAD/MAC. Impersonation → certificates + chain. Forward-secrecy harvesting → ephemeral DH. TLS is a layered system where each defence neutralizes a specific attack class.

Implementation Bugs: Heartbleed and Friends

The protocol can be sound while the code implementing it is flawed. The famous example is Heartbleed (2014): a buffer over-read bug in OpenSSL's TLS heartbeat extension let an attacker read up to 64 KB of server memory per request — potentially leaking private keys, session cookies, and passwords, with no trace in logs.

Heartbleed's deeper lesson: a leaked key means revoke AND rotate

Heartbleed mattered so much because it could expose the server's private key — and remember from Chapter 3 that without forward secrecy, a stolen key decrypts past recorded traffic too. The full remediation was a chain: patch OpenSSL → generate a new key → reissue the certificate → revoke the old certificate → and force-reset potentially exposed user credentials. Patching alone was not enough; any key that might have leaked must be treated as compromised. This is also a strong argument for forward secrecy (ephemeral DH), which limits how much a future key leak can retroactively expose.

Revocation: Cancelling a Certificate Before It Expires

When a key is compromised (as in Heartbleed) or a cert is mis-issued, you need to invalidate it before its natural expiry. That's revocation, and it has historically been the weakest link in the PKI:

Mechanism	How it works	Weakness
CRL	CA publishes a big list of revoked serial numbers	large, slow to download, cached stale
OCSP	browser asks the CA about one cert in real time	slow, privacy-leaking, often "soft-fail"
OCSP stapling	server staples a fresh CA-signed status (Ch. 10)	needs server support

The dirty secret: revocation checking often "soft-fails"

If a browser can't reach the CA to check revocation (responder down, network blocked), most browsers proceed anyway rather than block the page — otherwise a CA outage would break the web. But that means an attacker who can block the OCSP request can also suppress the revocation check. This unreliability is the real reason the industry shifted to short-lived certificates (Chapter 4's 90-day certs): if a cert is only valid for weeks, the damage window from a compromise is small even if revocation never reaches the client. Short lifetimes are revocation that actually works.

Certificate Pinning — Powerful and Dangerous

Pinning hard-codes which specific certificate or public key an app expects, so even a validly-issued cert from a different (possibly fraudulent) CA is rejected. It defends against the Chapter 5 risk of a misbehaving CA. But it's a sharp tool:

Pinning can brick your own site — it's largely deprecated for the web

If you pin a key and then have to rotate it (or your CA changes), every client still holding the old pin refuses to connect — you can lock out your entire user base with no easy recovery. Browser-based HTTP Public Key Pinning (HPKP) was so footgun-prone that browsers removed it. Pinning survives mainly in mobile apps (where you control both client and server and can ship updates) and high-security contexts. For the general web, Certificate Transparency (Chapter 12) is the preferred, safer answer to the rogue-CA problem.

Hands-On Exercises

Exercise 1

Use badssl.com (or openssl against it) to trigger several deliberate certificate errors — expired, wrong-host, self-signed, untrusted-root. For each, name the exact check that failed and which chapter's concept it maps to.

📄 View solution

Exercise 2

For each attack — (a) SSL stripping, (b) protocol downgrade, (c) passive eavesdropping, (d) a stolen server key used to decrypt old recorded traffic — name the specific TLS mechanism that defends against it and the chapter that introduced that defence.

📄 View solution

Exercise 3

A server running a vulnerable OpenSSL version is found to be exposed to Heartbleed. Write the full remediation checklist in the correct order, and explain why simply patching OpenSSL is insufficient. Then explain why short-lived certificates reduce reliance on revocation.

📄 View solution

Chapter 11 Quick Reference

Cert errors map to failed checks: DATE→validity, COMMON_NAME→SAN, AUTHORITY/local-issuer→chain (Ch. 4–5)
Mixed content — HTTP sub-resources on an HTTPS page; active (scripts) blocked, passive (images) warned; load all over HTTPS
SSL stripping → defeated by HSTS (Ch. 10); downgrade → defeated by the Finished hash + TLS 1.3 removing weak options
Heartbleed — an implementation bug (OpenSSL) leaking memory incl. private keys; protocol-sound ≠ code-safe
Key compromise = patch → new key → reissue → revoke old → reset credentials; patching alone is not enough
Revocation: CRL / OCSP / OCSP stapling — but checks often soft-fail, so short-lived certs are the real mitigation
Pinning defends against rogue CAs but can brick your site; browser HPKP was removed — survives mainly in mobile apps
Every attack maps to a defence already learned — TLS is layered, each mechanism neutralizing one attack class
Next chapter: beyond the basics — mTLS, Certificate Transparency, and the modern PKI ecosystem