HTTPS Is Just Maths and a Trust Fall

I set up my own internal certificate authority for a homelab project a while back, mostly to understand what a browser actually checks when it shows that padlock icon everyone trusts without a second thought. Watching a browser flatly refuse a self-signed certificate — one I knew, with total certainty, was protecting a genuine, uninterceptable connection to my own server — clarified something HTTPS explanations usually gloss over. HTTPS bundles two entirely separate guarantees together: real, checkable mathematics proving nobody tampered with or read your traffic in transit, plus a social trust structure deciding whose word you accept about who’s on the other end of the connection. The maths is solid enough to bet a bank on. The trust structure is closer to a very well-organised trust fall, and understanding where one ends and the other begins explains almost every confusing thing HTTPS ever does to you.

The maths half: proving nobody read or altered your traffic

Every HTTPS connection starts with a TLS handshake, and the goal of that handshake is deceptively simple to state: two parties who’ve never spoken before need to agree on a shared secret key, over a channel that anyone might be listening to, without ever transmitting that key itself in a form an eavesdropper could use.

1
2
3
4
5
6

Client Hello  ──────────────────►  (supported ciphers, a random nonce)
              ◄──────────────────  Server Hello + certificate
                                    (chosen cipher, server's public key)
Key exchange  ──────────────────►  (client contributes to the shared secret)
              ◄──────────────────  Finished (both sides now share a secret key)
Application data, encrypted with the shared secret, flows both directions

Modern TLS (1.3) uses Diffie-Hellman key exchange to pull this off, and the elegance of it is worth sitting with: both sides can derive an identical shared secret through public exchanges that an eavesdropper watching every single message still can’t reconstruct, because computing the secret requires a private value neither side ever transmits.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# toy Diffie-Hellman, small numbers only — real TLS uses numbers
# hundreds of digits long, making brute force computationally infeasible
p, g = 23, 5                       # public: a shared prime and generator
a = 6                              # client's private secret, never sent
b = 15                             # server's private secret, never sent

A = pow(g, a, p)                   # client sends A publicly
B = pow(g, b, p)                   # server sends B publicly

client_secret = pow(B, a, p)       # client computes using A and its own a
server_secret = pow(A, b, p)       # server computes using B and its own b
assert client_secret == server_secret

Both sides land on the identical number, 2 in this toy example, without either one ever transmitting a or b themselves. An eavesdropper sees p, g, A and B — everything exchanged publicly — but reconstructing the shared secret from those requires solving the discrete logarithm problem, which is the specific hard mathematical problem the security of the whole exchange rests on. Real TLS uses primes hundreds of digits long specifically because the discrete logarithm problem gets exponentially harder as the numbers grow, not because bigger numbers are inherently more secure in some vague sense.

Why this half doesn’t need anyone to vouch for anyone

The genuinely elegant part is that this key exchange works between total strangers with zero prior trust — it proves two parties can agree on a secret an eavesdropper can’t derive, full stop, regardless of who either party actually is. That’s a real, checkable, provable mathematical guarantee, and it’s the half of HTTPS that deserves the confidence people place in the padlock icon.

The trust fall half: who says this is actually the real server

Diffie-Hellman proves you’ve established a private channel with somebody. It says nothing whatsoever about whether that somebody is your bank or an attacker sitting between you and your bank, quietly running the identical handshake with both sides — a man-in-the-middle attack works perfectly well against pure key exchange, because the maths never checks identity, only secrecy.

This is what certificates exist to solve, and it’s where HTTPS stops being pure mathematics and becomes a chain of vouching. A certificate is a statement — “this public key belongs to example.com” — signed by a certificate authority (CA) whose own signing key your browser was shipped trusting in advance, baked into the OS or browser as a root store. Verify a certificate chain by hand and the trust fall becomes visible:

1
2
3
4

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -noout -issuer -subject
# issuer=C=US, O=Let's Encrypt, CN=R3
# subject=CN=example.com

Your browser trusts that certificate because Let’s Encrypt’s root certificate is pre-installed in the browser’s trust store, and Let’s Encrypt vouched for the connection between that public key and that domain name — the browser does no independent mathematics of its own to check that example.com owns that key. Pull that thread all the way up and every HTTPS connection you’ve ever trusted terminates in a small number of root CAs whose public keys shipped with your operating system, trusted entirely on the strength of an industry-wide agreement about which organisations are allowed to make that vouching statement.

What “Domain Validation” actually validates

The most common way a CA decides a certificate request is legitimate is domain validation, and it’s worth knowing exactly how thin this check is, because it explains a lot about why certificate-based trust has limits. Let’s Encrypt’s DNS-01 challenge asks the requester to add a specific TXT record to the domain’s DNS:

1

_acme-challenge.example.com.  300  IN  TXT  "gfj9Xq...Rg85nM"

The CA queries that record, sees the expected value, and concludes whoever requested the certificate controls the DNS for that domain — which is a real, meaningful check, but it’s the entire check. Domain validation says nothing about the legal identity behind the domain, its reputation, or its intentions. It confirms domain control and nothing more, which is exactly why a certificate padlock has never meant “this site is trustworthy” — only “this connection genuinely goes to whoever currently controls this domain’s DNS,” a narrower and more honest claim than the icon’s reputation with ordinary users suggests.

Certificate pinning and mTLS: skipping the public trust fall entirely

Once you understand the trust fall as a separate, social layer bolted onto solid maths, the alternatives make immediate sense. mTLS between your own services sidesteps the public CA trust fall entirely for internal traffic — instead of trusting a public root store’s judgement about who’s allowed to vouch for certificates, you run your own private CA and explicitly configure every service to trust only that CA’s signature, nobody else’s. That’s a smaller, tighter trust fall, held between parties who actually know each other, rather than delegated outward to a public root store making judgement calls on your behalf.

Perfect forward secrecy: why capturing today’s traffic doesn’t help tomorrow

There’s a specific property of modern TLS worth understanding on its own, because it addresses a genuinely realistic threat: an attacker recording encrypted traffic today, hoping to decrypt it years later once they’ve somehow obtained the server’s private key. Older TLS versions used the server’s long-term private key directly as part of deriving the session’s shared secret, which meant a single leaked or stolen key could retroactively decrypt every recorded session that ever used it.

TLS 1.3 closes this by requiring ephemeral Diffie-Hellman for every single connection — the a and b values in the toy example above are freshly generated random numbers for every handshake, used once, and discarded immediately afterwards, never derived from or stored alongside the server’s long-term identity key. Even if the server’s long-term private key leaks next year, none of last year’s recorded sessions can be decrypted with it, because none of them depended on that key for the actual secret — only for signing the handshake and proving identity. This property, perfect forward secrecy, is why a certificate compromise is a serious incident but not automatically a retroactive disaster for every past connection to that server.

Why certificate revocation is the weakest link in the whole chain

The trust-fall half has one especially awkward failure mode: what happens when a CA needs to say “actually, ignore that certificate we vouched for, it was compromised” after already issuing it. Two mechanisms exist — Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) — and both share the same structural problem: checking revocation status requires either downloading a list or making a live network call before trusting a certificate, and if that check fails or times out, most browsers historically failed open, trusting the certificate anyway rather than blocking the user.

1
2
3

openssl x509 -in cert.pem -noout -ocsp_uri
# shows the OCSP responder URL a client would need to reach
# to confirm this specific certificate hasn't been revoked

Modern browsers have moved toward OCSP stapling — the server itself fetches and attaches a signed, time-stamped “not revoked” statement to the handshake, sparing the client a separate network round-trip — but the fundamental tension remains: revocation is a real-time trust-fall check bolted onto a system that otherwise validates entirely offline against a locally cached root store. It’s the part of HTTPS’s trust model that ages worst, and the reason certificate lifetimes have been shrinking industry-wide — a shorter-lived certificate limits how long a compromised one can cause damage even when revocation checking fails silently.

Troubleshooting: reading TLS errors through the two-halves model

• “Your connection is not private” / certificate not trusted. This is almost always a trust-fall failure, not a maths failure — either the certificate is self-signed with no CA vouching for it, the CA that issued it isn’t in your browser’s root store, or the certificate has expired. openssl s_client -connect host:443 -showcerts shows you the full chain to diagnose which link broke.
• Handshake failure with no certificate warning at all. This points to the maths half instead — a cipher suite mismatch, a TLS version mismatch (an old server offering only TLS 1.0 against a modern browser refusing anything below 1.2), or a middlebox mangling the handshake in transit.
• Certificate valid in a browser, but a script using curl rejects it. Check whether the script’s TLS library has an outdated or incomplete root store — curl --cacert pointing at a specific bundle, or updating ca-certificates on the system, usually resolves this without touching the server at all.
• mTLS connection fails even though the server certificate looks fine. mTLS requires the client to present its own certificate too, not just verify the server’s — check that the client is actually configured to send one, since a missing client certificate produces an error that often looks identical to a server-side misconfiguration.
• A certificate renewed fine last month but now the domain validation challenge fails. DNS-01 challenges depend on DNS propagation completing before the CA checks the TXT record — a slow or misconfigured DNS provider, or a shortened TTL that hasn’t taken effect yet, causes intermittent renewal failures that often resolve themselves on retry once propagation catches up.
• Revocation checking is silently not happening at all. Test with openssl s_client -connect host:443 -status and check for an OCSP response in the output; many deployments assume stapling is configured correctly when the server was never actually set up to fetch and attach one, leaving every client to fail open by default.

Is it worth reaching for

Splitting HTTPS into its two halves resolves most of the confusion people carry about it. The mathematics — Diffie-Hellman key exchange producing a shared secret an eavesdropper genuinely cannot derive — deserves every bit of confidence placed in it; it’s one of the most thoroughly analysed pieces of applied cryptography in existence. The trust fall — a small number of certificate authorities vouching for domain ownership, trusted because your OS shipped believing them — deserves a more measured kind of confidence, because it’s a social and institutional arrangement with real, documented failure modes: mis-issued certificates, compromised CAs, and domain validation that only ever proved DNS control, never intent. Both halves are doing genuine work. Knowing which one is failing when a padlock turns red is most of what separates calm troubleshooting from panic.