Certificates and certificate authorities

Three seals of increasing size, strung together by a ribbon; each seal presses its mark into the next.

To the left of the address bar there's a padlock. Click it and your browser says the connection is secured. But secured with whom? Someone can put up a site that looks exactly like your bank's, with encryption just as good. What your browser checks there in a tenth of a second is a certificate: a signed statement that the key on the other end belongs to that name. This chapter takes such a statement apart, field by field.

Words you might need

Certificate: A little file containing: a name, a public key, a period in which it is valid, and someone else's signature. That's all it is.
Certificate authority (CA): The body that signs that little file. It first checks whether the name is right, and then puts its signature under it. Often just called a CA.
X.509: The format such a certificate is written in. One agreement, the same the world over: on websites, on your ID card, in the wifi settings at school.
Subject and issuer: The two names in every certificate. The subject is who it is about; the issuer is who signed it.
Root certificate: A certificate that signs itself: subject and issuer are the same name. There is nobody above it. Well over a hundred of these are baked into your operating system and your browser.
Revoking: Declaring a certificate invalid before its end date, for instance because the private key has been stolen. Also called revocation.
DER and PEM: Two wrappings of the same certificate. DER is the raw bytes; PEM is those same bytes in base64 (chapter 1) with a line -----BEGIN CERTIFICATE----- in front of it, so you can paste it into an email.

The gap a signature leaves

In chapter 7.1 you signed something yourself and then verified it. What that check told you was this: the person who signed this had the private key belonging to this public key. That's all. There was no name attached. If I put together a key pair (chapter 6) and claim it belongs to your bank, then all my signatures check out perfectly — against my key.

A certificate fills that gap in the only way that works: someone else states it, and signs that statement. So a certificate is nothing new. It's the previous chapter, applied to a sentence that is itself about a key:

"The public key A1B2… belongs to www.mybank.be, from 1 March to 30 May."

— signed by: Let's Encrypt

What it literally says

An X.509 certificate consists of three parts: a block with all the data, the name of the signature system used, and the signature itself. That data block is called tbsCertificate, from to be signed: this is exactly the piece the hash (chapter 2) is computed over before anything is signed. Change one byte of it and the signature no longer fits.

Field	What's in it
`version`	Almost always v3. That's the version that allows extensions, and without extensions no modern site works.
`serialNumber`	A number the issuer never uses twice. It's also picked unpredictably, because that stops an attacker working out in advance what is going to be signed.
`issuer`	The name of whoever signs. This is the link upwards in the chain.
`validity`	Two moments in time: `notBefore` and `notAfter`. Outside that window the certificate is worthless, even if the signature is right.
`subject`	Who it is about: a domain name, a company, or in the case of your ID card a person.
`subjectPublicKeyInfo`	The public key itself, plus which system it is: RSA of so many bits, or ECDSA on curve P-256. This is what the whole certificate is about.
`extensions`	Separate extra fields. See below.
`signatureAlgorithm` `signatureValue`	What was signed with, and the signature. Note: this is the issuer's signature over everything above — not something the owner put there himself.

The three extensions that matter most in practice:

Extension	What for
`subjectAltName` (SAN)	The domain names this certificate is valid for. Browsers look here, and only here. One certificate can cover dozens of them.
`keyUsage`	What you may do with the key: put signatures, sign other certificates, sign revocation lists. A key that may only do `digitalSignature` may not issue certificates.
`basicConstraints`	If it says `CA=JA`, this holder may issue certificates itself. If it says `CA=NEE`, this is a terminus. This one little field is the difference between an ordinary website and a body allowed to sign for the whole world.

A number of extensions are marked critical. That means: whoever doesn't understand this extension must refuse the certificate. That way something can be added later without old software quietly reading straight past it.

The chain: from website to root

Let's Encrypt doesn't sign directly with the key that's in your browser. There's a link in between:

End certificate — subject: a domain name, for example www.enigmalab.be. Issuer: an intermediate certificate. Valid for a few months.
Intermediate certificate — for example subject R11, issuer ISRG Root X1. Valid from 13 March 2024 to 12 March 2027. Which intermediate certificates there are exactly varies; sometimes there are two below one another.
Root certificate — subject and issuer both: ISRG Root X1. Valid from 4 June 2015 to 4 June 2035. This certificate is already in your computer before you switch it on for the first time.

Your browser checks every step with the public key from the step above it. At the root it stops: that signature is from the root itself, so nothing there proves anything any more. You believe it because Microsoft, Apple, Google or Mozilla decided to ship it. That's not math any more, that's a company's decision.

How many of those roots do you trust without knowing it? The list Mozilla published on 13 August 2026 has 121 of them. Each of those 121 can make a valid certificate for any website in the world. The chain is as strong as the weakest root.

Why that step in between? Because the root's private key is offline, in a vault, in a device that won't hand it over. The intermediate certificate's key is online and signs all day long. If that gets stolen, you revoke the intermediate certificate and make a new one. The root — and with it every device in the world — doesn't have to be touched.

Look inside a certificate yourself

Everything happens in your browser. Nothing is sent to the server.

There's already a real certificate in the field: R11, the intermediate certificate of Let's Encrypt. Click Parse this certificate.
Look at subject and issuer. They differ: this certificate was signed by ISRG Root X1.
Click Root certificate. Now subject and issuer are the same name — and that name is exactly the issuer from a moment ago. That's one link of the chain, with your own eyes.
Among the extensions, look at basicConstraints. Both of them say CA=JA: these two are allowed to sign.
Change one letter in the base64 text and click again. The lengths in the format then no longer fit and you get an error — not half a result.
Want to see a subjectAltName? Click the padlock in your address bar, export the certificate of this or another site, open the file in a text editor and paste it here.

Certificate in PEM form

Who are those authorities, and what do they check?

A CA doesn't sell encryption. It sells a check. Everything depends on how thorough that check is, and that varies enormously.

What gets checked	How	So what it's worth to you
A domain name, at Let's Encrypt	The CA gives you a random number. You put it at `http://yourdomain/.well-known/acme-challenge/…` or in a DNS record. The CA fetches it from several places in the world at once.	That you're in charge of that domain. Not who you are. That's why the certificate literally says "domain validated".
A person, at your ID card	You walked into the town hall with your papers, an official saw your face, and the State already knew who you were.	Your real name and national register number. That's why that certificate is worth something legally — see chapter 8.2.

The first check costs nothing and takes thirty seconds; the second costs a trip to the town hall. They're both useful, but they prove something completely different. So a padlock in your browser doesn't say the company behind it is sound — only that the name in the address bar is right.

What happens when one of them fails

DigiNotar was a Dutch certificate authority from Beverwijk. Among other things it signed for the Dutch government: DigiD, the service Dutch people use to log in at the tax office, hung off it.

On 19 July 2011 the company noticed that its systems had been broken into. It kept quiet. On 10 July a false certificate for *.google.com had already been issued. At the end of August a user in Iran ran into a warning from Chrome: that browser knew which certificates belonged to Google, and this wasn't one of them. That's when it came out. At least 531 false certificates turned out to have been made. With the Google certificate, the mail traffic of an estimated 300,000 Iranian Gmail users had been read along with — in a country where that can cost people their freedom.

The browser makers then threw all DigiNotar certificates out of their list. That made the company worthless: a CA nobody trusts any more sells nothing. On 20 September 2011, less than a month after the discovery, DigiNotar was declared bankrupt.

One CA that fails doesn't break its own customers but everyone. That's the price of a system in which 121 roots are all allowed to do everything. Since then CAs have had to put every certificate they issue into public logs — Certificate Transparency — so that Google can see that somewhere a certificate for google.com has been made that Google didn't order. You'll see those log proofs in the demo with a certificate from a real website.

Revoking: invalid before the end date

A private key can leak. The holder can stop existing. Then the certificate has to be invalid immediately, and not only at notAfter. That's harder than it looks, because the certificate itself doesn't change — it's sitting on the attacker's disk and still looks perfect. So something has to be added that says: don't believe this any more.

Way	How	Problem
CRL certificate revocation list	The CA publishes a list of revoked serial numbers. Your browser fetches that list and checks whether your serial number is on it.	The list is big and lags behind reality.
OCSP online certificate status protocol	Your browser asks the CA live, per certificate: is this still valid?	You're telling the CA which sites you visit. And if the CA doesn't answer, browsers carry on anyway — otherwise half the web would be down.

That second objection has won. Let's Encrypt took the OCSP addresses out of its certificates on 7 May 2025 and switched the service off entirely on 6 August 2025, with privacy as the reason. You can see it back in the demo: a certificate from a real website does have a cRLDistributionPoints, but no OCSP address.

The real solution turned out to be simpler: make certificates so short-lived that revoking barely matters any more. A certificate that expires by itself after a few months is a stolen key that goes stale by itself. That's why a server nowadays renews its certificate automatically, well before it runs out, without a human being involved.

This is math: trust as a directed graph

Draw every certificate as an arrow: from the issuer to the subject. What you get is a directed graph — points with arrows between them — and the question "may I believe this website?" becomes the question "is there a path from a point I already trust to this point?". That's exactly the kind of question graph theory is about, the same field that works out how your route planner finds the shortest way.

That also makes it immediately visible where things went wrong at DigiNotar. In this graph there are 121 points where a path can begin, and from each of those points every other point is reachable. One compromised starting point is enough to fabricate a path to any name whatsoever. The math doesn't tell you here how to secure something, but how vulnerable the shape of your system is — and that's just as useful.