Notes on Certificates

Overview

Continuing with the series, we’ve seen that Symmetric Encryption needs a safe way to deliver keys, and Asymmetric Encryption becomes that delivery service; yet everything rests on an unspoken assumption: that the public key that we download really belongs to its claimed owner. “Eve” needs no mathematical breakthrough to break this assumption: she generates her own key pair and publishes it under Bob’s name, after which our beautifully encrypted messages travel straight into her hands. What we are missing is someone to vouch for the link between a key and an identity. That voucher is the certificate: a signed statement binding them together, working much like a passport, which proves nothing about the person carrying it but plenty about who issued it.

How it works

A Certificate Authority (CA) is an institution everyone agrees to trust. Before issuing anything, it checks Bob’s claim through other means (domain ownership, company documents), then produces a small structured file stating: this identity holds this public key, signed by me, valid between these dates:

Certificate:
 └─ Subject:   bob.example + Bob's public key
 └─ Issuer:    Honest Intermediate CA
 └─ Validity:  not before / not after
 └─ Signature: made with the issuer's private key

Note what signing means here: the CA locks the statement with its own private key (the reverse trick of encryption), so anyone can unlock it with the CA’s freely available public one. Only whoever holds that private key could have produced it, which turns the signature into proof of origin. In practice the CA does not sign the whole document but its Hashing fingerprint, which achieves the same guarantee far more cheaply. The whole mechanism deserves a story of its own, told on Signatures.

The chain of trust

Browsers cannot ship the public key of every CA on Earth, so trust is organised hierarchically: a handful of root CAs (pre-installed in our operating system) sign intermediate CAs, which in turn sign the certificates of actual websites. Verifying one link at a time up the chain, our browser eventually reaches a root it already knows by heart, and the whole structure stands or falls with that anchor. Roots stay offline precisely so that their precious keys are almost never used.

An example in practice

We can watch a server present its credentials during a TLS handshake:

openssl s_client -connect example.com:443 -showcerts
# Output includes the full chain:
# 0 s:CN = example.com          (the site's own certificate)
# 1 s:C = US, O = Let's Encrypt (the intermediate that signed it)
# ...followed by the handshake continuing

openssl x509 -in cert.pem -text -noout
# Issuer: C = US, O = Let's Encrypt, CN = R3
# Validity
#     Not Before: Aug  1 00:00:00 2026 GMT
#     Not After : Oct 30 23:59:59 2026 GMT

The first command shows who is vouching; the second reads the certificate itself, where the issuer and validity window live.

The catch

Certificates do not eliminate trust; they concentrate it. Everything now depends on CAs behaving honestly and keeping their private keys safe, because a single mis-issued or stolen certificate lets an attacker impersonate anyone. It has happened: in 2011 the Dutch CA DigiNotar was compromised and fraudulent google.com certificates appeared in the wild, which ended with the company’s bankruptcy.

Browsers respond by revoking trust after the fact, patching the hole once found, but the lesson remains: cryptography hands us statements we can prove (a signature either does or does not verify it), whereas certificates hand us promises we must take on faith (that the CA checked Bob honestly before signing). Only one of those ever comes with proof attached.