Build your own certificate

Three stacked blocks, each pressing a stamp into the one above; the bottom block rests on bare ground.

The padlock on the left of your address bar says: you really are at the site that's written there, and not at somebody pretending to be it. Behind that padlock sits a certificate. Below you'll make two of them yourself — with real keys, real signatures and a real check. Everything will be correct. And still no browser would accept them, and not because there's a calculation error somewhere.

Words you'll need in a moment

Certificate: A statement of the form "this public key belongs to this name", signed by someone else. What such a statement looks like in real life is in chapter 7.2; here you build one yourself.
Subject and issuer: The two names in every certificate. Subject is who it's about, issuer is who signed it. These are the words you'll see, because that's literally how they appear in the fields.
CA: Certification authority: a party that issues certificates for others. In the demo that's you.
Root certificate: The certificate right at the top, which signs itself. Its subject and issuer are identical. "Root" because the chain stops there, the way a tree in a diagram stands upside down.
Self-signed: Signed with the private key belonging to the public key in the certificate itself. It proves you have that key, and nothing more — you're only saying about yourself that you're trustworthy.
End certificate: The certificate at the bottom of the chain, for a real name: a website, a person. Your bank's is one of those.
Trust anchor: The key where you stop checking because you simply believe it. Every chain ends at one of those. This word is the heart of this chapter.
Fingerprint: The hash of a key or a certificate, written as hex with colons. Short enough to compare, and unique enough to serve as a name.
JSON: A way of writing down data with curly brackets and "name": value. You'll see it in the output in a moment.

What you're going to build

Two certificates and one signature in between. That's the smallest chain there is, and it works exactly like the chain behind your bank's padlock — except that one usually holds three certificates: the site's end certificate, an intermediate certificate, and the root.

	Root certificate	End certificate
subject	My own root CA	the name you type in
issuer	My own root CA	My own root CA
key pair	its own	a new one of its own
who puts the signature	the root, over itself	the root, over the end certificate
what it proves	that someone has that private key	that the root ties this name to this key

The end certificate's private key never leaves its owner. The root signs a statement about a public key, and doesn't need the matching private key for that. That's the same separation as in chapter 6.

Our certificate is JSON, a real certificate is DER

The demo writes a certificate as JSON, because you can read that. A real certificate holds the same core — serial number, subject, issuer, the validity window, the public key — but sits in DER, a binary way of writing in which every field has a fixed place and a fixed length. Those fields and what else comes with them are in chapter 7.2.

Why binary, and not just JSON? A signature is over bytes, not over meaning. Add one space in JSON, or swap two fields around, and they're different bytes while it says the same thing: the signature no longer matches. The demo solves that by always writing out exactly the same fields in exactly the same order before it signs. DER does the same thing, but as an agreement nobody can deviate from. That's the only reason a certificate looks unreadable.

Build your own chain

Everything happens in your browser. The keys are made here and go nowhere; close the tab and they're gone.

Click Make a root certificate. Look in the JSON for the fields subject and issuer: the same name. This certificate says about itself that it's correct.
Type a name — your first name, or a made-up domain like sam.be — and click Make an end certificate. Look at x and y: those are the coordinates of a point on the curve from chapter 6.2, and they're different from the root's. A new key pair.
Click Check the chain. The demo takes the public key out of the root certificate and uses it to check the signature under the end certificate. Valid.
Click Change one letter in the name. The signature stays, the dates stay, one character changes — and the check runs again straight away. Invalid. This is the most important button in this chapter: that's how you know nobody can alter a certificate without the issuer's private key.
Click Put the name back. Valid again, without anything being signed anew.
Click Judge it like a browser. Four checks, three times YES and once NO. Read that fourth line carefully.

Name for the end certificate

Everything is correct, and still nobody believes you

Your chain is mathematically in order. Every signature is real, every check succeeds, and the keys are the same kind as the ones behind the padlock of real sites: ECDSA on the curve P-256, exactly what you used yourself in chapter 7.1. Put this on a web server and you'll still get a red warning across your whole screen.

The reason is in that fourth line of the last button. Your browser checks the signatures, climbs the chain, and arrives at your root. There it asks one question: is this root in my list? That's a real list with real fingerprints, shipped along with the browser. Firefox uses Mozilla's, with around a hundred and fifty roots in it; Chrome, Safari and Windows each have one from Google, Apple and Microsoft. Your root is in none of those four, because you made it thirty seconds ago.

So there's no mathematical difference between your certificate and your bank's. The difference is that somebody put your bank's CA on a list, and not you. To get on it, a CA has to be vetted, follow rules and have that checked again every year.

What a real CA does before it signs

A CA issuing a certificate for sam.be first wants to know whether you really control that domain. Usually that happens automatically: put a particular file on the server, or a particular line in the domain's DNS, and the CA goes to look whether it's there. If you can do that, you control the domain. Let's Encrypt does it that way, free, and that's why just about every site has a padlock today.

Your root	A root from the list
Signs whatever you ask.	Only signs after a check on who the applicant is or what they control.
Exists in one tab.	Sits in hundreds of millions of devices, for years.
Nobody is watching.	Yearly audits, public rules, and every certificate issued goes into a public log.
Gone when you close your browser.	Should the private key ever leak, the root has to come off all the lists — and that breaks every site under it at once.

A list can be changed. Add your root to the list on your own laptop, and your own certificates work straight away without a warning. Schools and companies do that on their devices, and there's a catch: whoever gets a root into your list can make a valid certificate for any site and sit between you and the internet without the padlock showing a thing. See chapter 7.4 for what that padlock is then still worth.

The same chain sits in the chip of your ID card, but with the Belgian State as the CA instead of you: a State root at the top, and under it a certificate for your card with your name in it. What's exactly on it and how you get that signature put there, you do in chapter 8.2.

This is math: where the math stops

Every step in your chain can be recalculated. The signature under the end certificate: checkable with the key from the root certificate. The signature under the root certificate: checkable with its own key. But that last check adds nothing — whoever has the private key can sign whatever they like about themselves. At the top of every chain sits a key you can't recalculate, only believe. That is the trust anchor.

That's not a weakness in the design; it's how proofs work. In mathematics you start with axioms: statements you accept, because you have to start somewhere. In cryptography the field that works this out is called provable security, and the theorems there all have the same shape: if this assumption holds, then this system is secure. Never "this is secure", always "if …, then …".

The trust anchor is the internet's axiom. Only here it isn't a mathematical statement but an organisation, and the list of axioms is managed by four companies. That's where the math stops and the agreement begins — and it's useful to know exactly where that line lies.

This is as far as it goes

This is the last chapter. You started at text that looked like secret writing and wasn't, and after that you hashed things yourself, cracked passwords, encrypted with AES, agreed a secret with everybody watching, added points on a curve, put a signature and broke it, sent messages only your friend can read, got the chip in your ID card to sign, and now built a certificate chain. None of it was faked: it's the same math that runs behind your bank's padlock.

What you also know now is where that math stops. Encryption sees to it that nobody reads along and that nobody changes anything unnoticed. Who you trust on the other side is a decision made by people. That isn't a hole in the technology — it's the place where you still have a say.