Certificates and PKI

Encryption keeps a conversation private, but it can't tell you who's on the other end. Certificates fill that gap. They're how your browser knows the site claiming to be your bank really is your bank.

Who are you talking to?

In the elliptic-curve Diffie–Hellman lesson, your browser and a server agreed on a secret key in full public view. Nobody listening could work out that key. But there's a catch: the exchange works just as well with an attacker.

Suppose someone on the same café Wi‑Fi intercepts your connection. They run one key exchange with you, pretending to be the bank, and another with the bank, pretending to be you. Both connections are encrypted, and the attacker reads everything as it passes through. This is a man-in-the-middle attack, and key exchange alone can't stop it.

What's missing is a way for the server to prove its identity. That proof is a certificate, and the system of organisations, rules and software that makes certificates trustworthy is called public key infrastructure, or PKI.

Digital signatures in one minute

Certificates are built on digital signatures, which use a key pair in the opposite way to encryption:

• The private key signs. Only its owner can produce a valid signature.
• The public key verifies. Anyone can check that a signature was made by the matching private key.
• The signature covers the exact contents. Change a single character afterwards and verification fails.

In practice, the signer hashes the message first and signs the short hash. Common signature algorithms are ECDSA, Ed25519 and RSA. A signature proves two things at once: who signed, and that nothing has changed since.

What's in a certificate

A certificate is a small document that says, in effect, “this public key belongs to shop.example.com”, signed by an organisation your browser already trusts. That organisation is a certificate authority (CA). Web certificates follow a standard format called X.509. Here's one decoded:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 04:f2:a9:10:c3:5e:7b:21
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=Example Trust, CN=Example Issuing CA E1
        Validity
            Not Before: Oct  1 00:00:00 2026 GMT
            Not After : Dec 30 23:59:59 2026 GMT
        Subject: CN=shop.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:shop.example.com, DNS:www.shop.example.com
            CT Precertificate SCTs:
                Signed Certificate Timestamp: (2 entries)
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:21:00:b7:3c:…

You can look at any site's certificate yourself. In most browsers, click the icon to the left of the address, then look for the connection or certificate details. From a terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | openssl x509 -noout -text

The chain of trust

Your browser doesn't know every CA's key in advance. It knows a short list of root certificates, a hundred or so, that ship with your operating system or browser in a trust store. Everything else has to be traced back to one of them.

Root CAs rarely sign website certificates directly. Their private keys are kept offline in secure hardware and used only occasionally, to sign intermediate CA certificates. The intermediates do the day-to-day signing. If an intermediate is compromised, it can be revoked without replacing a root on billions of devices.

So a server sends a chain: its own certificate (the leaf), plus the intermediate that signed it. Your browser checks each link, then confirms the chain ends at a root it already trusts.

Notice that the “Unknown root” chain is perfectly signed. Every signature checks out. Anyone can create a root certificate in seconds; what makes a root matter is being in your trust store. Getting there requires years of audits, which is why companies that install their own root on staff laptops (to inspect traffic) can read everything those laptops send.

How a certificate is issued

For a long time, getting a certificate meant filling in forms and paying a fee. Since Let's Encrypt launched in 2015, most sites get free certificates automatically using a protocol called ACME.

1. Generate a key pair The server creates its own key pair. The private key never leaves the server.
2. Send a certificate signing request The request contains the public key and the domain names wanted, and is signed with the private key to prove the requester holds it.
3. Prove control of the domain The CA sets a challenge. Either serve a specific file at http://domain/.well-known/acme-challenge/, or publish a specific DNS record at _acme-challenge.domain. Only someone who controls the domain can do either.
4. The CA logs and signs The CA submits the certificate to public Certificate Transparency logs, then signs it with an intermediate key and sends it back.
5. Install and renew automatically Software such as Certbot installs the certificate and repeats the process before it expires, with no human involved.

This is domain validation (DV): it proves control of a domain, not who runs it. Organisation validation (OV) and extended validation (EV) add checks on the company behind the site, but browsers stopped showing that extra information prominently around 2019, because studies found people didn't notice it.

When a key is stolen

If a server's private key leaks, its certificate needs to stop working before its expiry date. The CA revokes it by publishing its serial number. Getting that news to every browser has always been the weak spot of PKI.

• Certificate revocation lists (CRLs) are files of revoked serial numbers published by each CA. They can grow large.
• OCSP lets a browser ask the CA about one certificate at a time. It's slow, it tells the CA which sites you visit, and if the CA doesn't answer, browsers usually carry on anyway. Let's Encrypt shut down its OCSP service in 2025 for these reasons.
• Browser-pushed lists are the modern approach. Chrome and Firefox collect revocation data centrally and push compact summaries to browsers in the background.

Short certificate lifetimes help here too. A stolen key for a certificate that expires in weeks is a much smaller problem than one valid for years.

Certificate Transparency

The whole system rests on CAs only signing what they should. Occasionally one hasn't. In 2011, a hacked Dutch CA called DigiNotar issued fake certificates for Google that were used to spy on users in Iran. DigiNotar was removed from every trust store and went bankrupt within weeks.

Certificate Transparency (CT) makes this kind of mistake visible. Every publicly trusted certificate must be recorded in public, append-only logs run by independent organisations. The log returns a signed receipt, and browsers like Chrome and Safari reject certificates that don't carry enough of them. These are the “SCTs” in the certificate above.

Anyone can search the logs. Site owners can watch for certificates issued for their domains that they didn't request, and researchers can spot a CA misbehaving within hours instead of months. Search tools such as crt.sh let you look up any domain.

Why this matters

• Encryption needs identity. Without certificates, a man in the middle could run a separate encrypted connection with each side.
• A certificate is a signed claim. It binds a public key to domain names, and a CA's signature vouches for it.
• Trust flows down a chain. Leaf to intermediate to a root already in your trust store. Every link must verify.
• The system watches itself. Revocation, short lifetimes and Certificate Transparency limit the damage when keys leak or CAs make mistakes.