Digital signatures, certificates and TLS

Digital signatures

A signature binds a message to its author. The mechanism reuses asymmetric keys backwards from encryption:

1. Hash the message (you sign the digest, not the whole thing, since it's faster and produces a fixed size).
2. Encrypt the digest with your private key; that's the signature.
3. A verifier hashes the message themselves, decrypts your signature with your public key, and checks the two digests match.

A match proves three things at once: the message wasn't altered (integrity, since any change breaks the digest), it came from the private-key holder (authenticity), and the signer can't credibly deny it (non-repudiation, since only they have the private key). That last property is what a shared-key MAC can't give you.

The gap this leaves: verification only proves the message came from whoever owns that public key. Whose key is it? Nothing so far stops an attacker handing you their key while claiming to be your bank. Certificates close that gap.

Certificates and PKI

A digital certificate (X.509) binds a public key to an identity (a domain name, an organisation). It's believable because it's signed by a Certificate Authority (CA), a third party your system already trusts. The certificate states "this public key belongs to example.com," and the CA's signature vouches for it.

The whole arrangement of CAs, certificates, registration and revocation is PKI (Public Key Infrastructure).

Chain of trust: your browser ships with a root store of trusted CA certificates. A site's certificate is usually signed by an intermediate CA, which is signed by a root CA in your store. Verification walks the chain (leaf → intermediate → root), checking each signature until it reaches a root you already trust. Roots are self-signed; trust has to bottom out somewhere, and it bottoms out in the list baked into your OS/browser.

Validation levels: Domain Validation (DV, which just proves control of the domain; what Let's Encrypt issues free and automatically), Organisation Validation, and Extended Validation. Note that browsers no longer give EV special UI, so the practical security difference is small.

Revocation: certificates can be cancelled before they expire (key compromised, domain sold). Mechanisms: CRL (certificate revocation lists, bulky) and OCSP (online status checks, privacy-leaky and slow), with OCSP stapling as the fix (the server attaches a fresh signed status, sparing the client a separate lookup). Revocation is the genuinely weak link in PKI; failures often "fail open."

Why trust a CA at all? Because verifying every site's key by hand doesn't scale. PKI centralises trust into a few hundred audited CAs. The cost is that a single compromised or coerced CA can issue a valid certificate for any site. Certificate Transparency logs (public, append-only records of every issued certificate) exist to catch that misuse after the fact.

TLS

TLS (Transport Layer Security) is the protocol behind HTTPS, secure email, VPNs and more. ("SSL" is its dead predecessor; SSL 2.0/3.0 and TLS 1.0/1.1 are all deprecated. Use TLS 1.2 or 1.3.) Every HTTPS page load runs a TLS handshake that delivers all three security properties:

• Authentication: the certificate proves you're talking to the real server (and optionally the client, in mutual TLS).
• Key exchange: ephemeral ECDH establishes a fresh symmetric session key (forward secrecy).
• Confidentiality + integrity: bulk traffic encrypted with AES-GCM or ChaCha20-Poly1305 (AEAD).

It's the hybrid model from the asymmetric chapter, productised. The TLS 1.3 handshake (2018) streamlined this to one round trip, dropped every legacy/insecure option (RSA key exchange, CBC modes, RC4), and made forward secrecy mandatory, a rare case of a protocol getting simpler and safer at once.

A subtlety students miss: TLS secures data in transit only. Once decrypted at the server it's plaintext again; TLS says nothing about encryption at rest. "The site uses HTTPS" and "the database is encrypted" are unrelated claims.

Putting it together: visiting an HTTPS site

1. Client connects, says which TLS versions/ciphers it supports.
2. Server sends its certificate chain.
3. Client validates the chain to a trusted root, checks the domain matches and the cert hasn't expired or been revoked.
4. Both run ephemeral ECDH to agree a session key; the server proves it owns the private key matching the certificate.
5. Symmetric encrypted communication begins.

If step 3 fails, the browser shows the certificate warning everyone clicks through. That's exactly how TLS-stripping and rogue-cert attacks succeed.

Quick recall

• Sign with private key (over the hash), verify with public key → integrity + authenticity + non-repudiation.
• A certificate binds a public key to an identity; a CA's signature makes it trustworthy.
• Chain of trust: leaf → intermediate → self-signed root in your browser's store.
• A single rogue CA can forge any site's cert; Certificate Transparency logs catch it afterwards.
• TLS 1.3 = mandatory forward secrecy, one round trip, legacy options removed. Use 1.2/1.3 only.
• TLS protects data in transit, not at rest.