Digital signatures & certificates

Key takeaways A signature is made by signing with a private key and checked by verifying with the matching public key. A valid one proves authenticity + integrity — who sent something, and that it wasn’t changed. But a key alone doesn’t say whose it is: certificates and PKI fix that by binding an identity to a public key, vouched for through a chain of trust. Together they answer “did this really come from them, untampered?” — building on symmetric & asymmetric crypto.

Encryption keeps a message secret. Signatures answer a different, equally important question: can I trust where this came from? Almost every secure system you touch — websites, app updates, package managers — leans on signatures and certificates to know it’s talking to the real thing.

How a signature works

A digital signature reuses the public/private key pair from asymmetric crypto, but runs it in the opposite direction from encryption.

  1. The signer takes the message and computes a hash of it — a short, fixed-size fingerprint.
  2. They encrypt that hash with their private key. The result is the signature, attached alongside the message.
  3. Anyone can verify it: hash the received message themselves, then use the signer’s public key to check the signature against that hash.

If the two match, three things follow at once:

  • Authenticity — only the private-key holder could have produced a signature that verifies with their public key.
  • Integrity — change one bit of the message and the recomputed hash won’t match, so verification fails.
  • Non-repudiation — the signer can’t credibly deny it later, because nobody else has their private key.

Note the signature does not hide the message. It travels next to readable content and simply proves the content’s origin and that it’s intact.

The identity problem

Here’s the gap. A signature that verifies with “this public key” only tells you the message came from whoever holds the matching private key. It says nothing about who that is.

An attacker can generate their own key pair, sign a fake message, and hand you the matching public key. The math checks out perfectly — it just proves the forgery was signed by the forger. A public key on its own is an anonymous string of bytes. Something has to connect a key to a real-world identity you can trust.

That something is a certificate.

Certificates & PKI

A certificate binds an identity — a domain name, a person, or an organization — to a public key. Crucially, the certificate is itself signed, by a trusted third party called a Certificate Authority (CA). The CA’s signature is a statement: “we verified that this public key really belongs to this identity.”

This whole arrangement — the CAs, the certificates, and the rules for issuing and checking them — is called PKI (Public Key Infrastructure).

Trust doesn’t hang on a single signer. Your device ships with a built-in list of root CAs it trusts. A root CA can sign an intermediate CA’s certificate, which in turn signs an end-entity certificate — a chain of trust. To trust the certificate in front of you, your device follows that chain link by link back to a root it already trusts. Break any link and the trust collapses.

Root CA Intermediate Site cert signs signs trusted by device
A chain of trust: your device trusts the root, the root vouches for the intermediate, the intermediate vouches for the site.

Where you rely on it

You lean on signatures and certificates constantly, usually without noticing:

  • HTTPS certificates — the padlock in your browser means a CA-signed certificate proved the site’s identity before any traffic flowed. See TLS & HTTPS.
  • Signed software updates (code signing) — your operating system and apps verify a vendor’s signature before installing an update, so tampered or spoofed updates are rejected.
  • Signed packages — package managers check signatures so you install what the maintainer actually published, not a swapped-out copy.
  • Signed emails — a signature lets a recipient confirm a message really came from the sender and wasn’t altered in transit.

In each case a fake, mismatched, or expired certificate is a red flag. When your device refuses one, the binding between identity and key couldn’t be verified — that warning is doing its job.

Trust, and its limits

Signatures and certificates are powerful, but they’re not magic. The system is only as trustworthy as the CAs it rests on and how well private keys are guarded.

  • If a CA is careless or compromised, it can issue certificates for names it never should have — and everything under it inherits that mistake.
  • If a signer’s private key is stolen, the thief can produce signatures that verify perfectly. The math still says “authentic” because, as far as the key is concerned, it is. This is why protecting private keys is its own discipline — see secrets management (coming up).

The takeaway: a valid signature proves control of a key, and a certificate proves someone once vouched for that key’s owner. Both are only as strong as the humans and processes behind them.

Quick check: a valid digital signature on a message proves what?

Recap

  • A signature is made by signing with a private key and checked by verifying with the public key.
  • A valid signature proves authenticity, integrity, and non-repudiation — but not whose key it is.
  • A certificate binds an identity to a public key and is itself signed by a Certificate Authority.
  • PKI and the chain of trust let your device follow signatures back to a root CA it already trusts.
  • You rely on this for HTTPS, code signing, signed packages, and signed email; a fake or expired certificate is a red flag.
  • The whole system is only as strong as the CAs and your private-key handling — a stolen key breaks it.

Next up: cryptography in practice