Zertifikate und Zertifizierungsstellen

Drei Siegel in wachsender Größe, mit einem Band aneinandergereiht; jedes Siegel drückt seinen Stempel in das nächste.

Links neben der Adressleiste steht ein Schloss-Symbol. Klick darauf, und dein Browser sagt dir, dass die Verbindung gesichert ist. Aber gesichert mit wem? Jemand kann eine Seite hinstellen, die genauso aussieht wie die deiner Bank, mit genauso guter Verschlüsselung. Was dein Browser dort in einer Zehntelsekunde prüft, ist ein Zertifikat: eine signierte Erklärung, dass der Schlüssel auf der anderen Seite zu diesem Namen gehört. Dieses Kapitel nimmt so eine Erklärung auseinander, Feld für Feld.

Wörter, die du gleich brauchst

Zertifikat: Eine kleine Datei, und darin steht: ein Name, ein öffentlicher Schlüssel, ein Zeitraum, in dem sie gilt, und die Signatur von jemand anderem. Mehr ist es nicht.
Zertifizierungsstelle (CA): Die Stelle, die diese kleine Datei signiert. Sie prüft zuerst, ob der Name stimmt, und setzt dann ihre Signatur darunter. Auf Englisch certificate authority.
X.509: Das Format, in dem so ein Zertifikat geschrieben ist. Eine einzige Absprache, überall auf der Welt dieselbe: auf Websites, auf deiner eID, in den WLAN-Einstellungen deiner Schule.
Subject und Issuer: Die beiden Namen in jedem Zertifikat. Das Subject ist der, um den es geht; der Issuer ist der, der es signiert hat.
Wurzelzertifikat: Ein Zertifikat, das sich selbst signiert: Subject und Issuer sind derselbe Name. Darüber sitzt niemand mehr. Über hundert davon stecken fest eingebaut in deinem Betriebssystem und in deinem Browser.
Widerrufen: Ein Zertifikat vor dem Enddatum für ungültig erklären, zum Beispiel weil der private Schlüssel gestohlen wurde. Heißt auch Revokation.
DER und PEM: Zwei Verpackungen desselben Zertifikats. DER sind die rohen Bytes; PEM sind dieselben Bytes in Base64 (Kapitel 1) mit einer Zeile -----BEGIN CERTIFICATE----- davor, damit du es in eine E-Mail kleben kannst.

Die Lücke, die eine Signatur lässt

In Kapitel 7.1 hast du selbst etwas signiert und es danach verifiziert. Was dir diese Prüfung gesagt hat, war das: Die Person, die das signiert hat, hatte den privaten Schlüssel, der zu diesem öffentlichen Schlüssel gehört. Mehr nicht. Ein Name stand nirgends dabei. Bastle ich mir ein Schlüsselpaar (Kapitel 6) zusammen und behaupte, es gehöre deiner Bank, dann stimmen all meine Signaturen perfekt — nur eben gegen meinen eigenen Schlüssel.

Ein Zertifikat füllt diese Lücke auf die einzige Art, die funktioniert: jemand anderes erklärt es und signiert diese Erklärung. Ein Zertifikat ist also nichts Neues. Es ist das vorige Kapitel, angewendet auf einen Satz, der selbst von einem Schlüssel handelt:

„Der öffentliche Schlüssel A1B2… gehört zu www.meinebank.be, vom 1. März bis zum 30. Mai.“

— signiert von: Let's Encrypt

Was wortwörtlich drinsteht

Ein X.509-Zertifikat besteht aus drei Teilen: einem Block mit allen Daten, dem Namen des verwendeten Signatursystems und der Signatur selbst. Dieser Datenblock heißt tbsCertificate, von to be signed: genau über dieses Stück wird der Hash (Kapitel 2) berechnet, bevor überhaupt signiert wird. Ändere ein einziges Byte daran, und die Signatur stimmt nicht mehr.

Feld	Was drinsteht
`version`	Fast immer v3. Das ist die Version, die Erweiterungen erlaubt, und ohne Erweiterungen funktioniert keine einzige moderne Seite.
`serialNumber`	Eine Nummer, die der Aussteller nie zweimal verwendet. Sie wird außerdem unvorhersehbar gewählt, denn dadurch kann ein Angreifer nicht vorher ausrechnen, was signiert werden wird.
`issuer`	Der Name dessen, der signiert. Das ist das Glied nach oben in der Kette.
`validity`	Zwei Zeitpunkte: `notBefore` und `notAfter`. Außerhalb dieses Fensters ist das Zertifikat wertlos, auch wenn die Signatur stimmt.
`subject`	Um wen es geht: ein Domainname, eine Firma, oder bei deiner eID eine Person.
`subjectPublicKeyInfo`	Der öffentliche Schlüssel selbst, dazu welches System es ist: RSA mit so und so vielen Bits, oder ECDSA auf der Kurve P-256. Darum dreht sich das ganze Zertifikat.
`extensions`	Einzelne zusätzliche Felder. Siehe unten.
`signatureAlgorithm` `signatureValue`	Womit signiert wurde, und die Signatur. Achtung: Das ist die Signatur des Ausstellers über alles hier darüber — nicht etwas, das der Besitzer selbst daruntergesetzt hat.

Die drei Erweiterungen, auf die es in der Praxis am meisten ankommt:

Erweiterung	Wofür
`subjectAltName` (SAN)	Die Domainnamen, für die dieses Zertifikat gilt. Browser schauen hier nach, und nur hier. Ein einziges Zertifikat kann Dutzende davon abdecken.
`keyUsage`	Was du mit dem Schlüssel machen darfst: Signaturen setzen, andere Zertifikate signieren, Widerrufslisten signieren. Ein Schlüssel, der nur `digitalSignature` darf, darf keine Zertifikate ausstellen.
`basicConstraints`	Steht da `CA=JA`, dann darf dieser Inhaber selbst Zertifikate ausstellen. Steht da `CA=NEE`, dann ist hier Endstation. Dieses eine winzige Feld ist der Unterschied zwischen einer gewöhnlichen Website und einer Stelle, die für die ganze Welt signieren darf.

Einige Erweiterungen sind als kritisch markiert. Das heißt: Wer diese Erweiterung nicht versteht, muss das Zertifikat ablehnen. So kann später etwas dazukommen, ohne dass alte Software stillschweigend darüber hinwegliest.

Die Kette: von der Website bis zur Wurzel

Let's Encrypt signiert nicht direkt mit dem Schlüssel, der in deinem Browser steckt. Dazwischen sitzt noch ein Glied:

Endzertifikat — Subject: ein Domainname, zum Beispiel www.enigmalab.be. Issuer: ein Zwischenzertifikat. Gültig ein paar Monate.
Zwischenzertifikat — zum Beispiel Subject R11, Issuer ISRG Root X1. Gültig vom 13. März 2024 bis zum 12. März 2027. Welche Zwischenzertifikate es genau gibt, wechselt; manchmal liegen zwei untereinander.
Wurzelzertifikat — Subject und Issuer: ISRG Root X1. Gültig vom 4. Juni 2015 bis zum 4. Juni 2035. Dieses Zertifikat steckt schon in deinem Computer, bevor du ihn zum ersten Mal einschaltest.

Jeden Schritt prüft dein Browser mit dem öffentlichen Schlüssel aus dem Schritt darüber. Bei der Wurzel hört es auf: Diese Signatur stammt von der Wurzel selbst, dort beweist also nichts mehr etwas. Du glaubst ihr, weil Microsoft, Apple, Google oder Mozilla beschlossen haben, sie mitzuliefern. Das ist keine Mathematik mehr, das ist die Entscheidung einer Firma.

Wie vielen dieser Wurzeln vertraust du, ohne es zu wissen? In der Liste, die Mozilla am 13. August 2026 veröffentlicht hat, stehen 121. Jede einzelne dieser 121 kann für wirklich jede Website der Welt ein gültiges Zertifikat erzeugen. Die Kette ist so stark wie die schwächste Wurzel.

Warum dieser Zwischenschritt? Weil der private Schlüssel der Wurzel offline liegt, in einem Tresor, in einem Gerät, das ihn nicht herausgibt. Der des Zwischenzertifikats steht sehr wohl online und signiert den ganzen Tag. Wird der gestohlen, dann widerrufst du das Zwischenzertifikat und machst ein neues. Die Wurzel — und damit jedes Gerät der Welt — muss nicht angefasst werden.

Schau selbst in ein Zertifikat

Alles passiert in deinem Browser. Es wird nichts an den Server geschickt.

Im Feld steht schon ein echtes Zertifikat: R11, das Zwischenzertifikat von Let's Encrypt. Klick auf Dieses Zertifikat zerlegen.
Schau dir Subject und Issuer an. Sie sind verschieden: Dieses Zertifikat wurde von ISRG Root X1 signiert.
Klick auf Wurzelzertifikat. Jetzt sind Subject und Issuer derselbe Name — und dieser Name ist genau der Issuer von eben. Das ist ein Glied der Kette, mit deinen eigenen Augen gesehen.
Schau bei den Erweiterungen auf basicConstraints. Bei beiden steht CA=JA: Diese zwei dürfen signieren.
Ändere einen einzigen Buchstaben im Base64-Text und klick noch einmal. Dann stimmen die Längen im Format nicht mehr und du bekommst einen Fehler — kein halbes Ergebnis.
Willst du einen subjectAltName sehen? Klick auf das Schloss-Symbol in deiner Adressleiste, exportiere das Zertifikat dieser oder einer anderen Seite, öffne die Datei in einem Texteditor und füge sie hier ein.

Zertifikat in PEM-Form

Wer sind diese Stellen, und was prüfen sie?

Eine CA verkauft keine Verschlüsselung. Sie verkauft eine Prüfung. Alles hängt davon ab, wie gründlich diese Prüfung ist, und da gibt es riesige Unterschiede.

Was geprüft wird	Wie	Was es dir also bringt
Ein Domainname, bei Let's Encrypt	Die CA gibt dir eine zufällige Nummer. Du legst sie unter `http://deinedomain/.well-known/acme-challenge/…` ab oder in einen DNS-Eintrag. Die CA holt sie von mehreren Orten der Welt gleichzeitig ab.	Dass du über diese Domain bestimmst. Nicht, wer du bist. Deshalb steht im Zertifikat wortwörtlich „domainvalidiert“.
Eine Person, bei deiner eID	Du bist mit deinen Papieren zum Gemeindehaus gegangen, ein Beamter hat dein Gesicht gesehen, und der Staat wusste ohnehin schon, wer du bist.	Dein echter Name und deine Nationalregisternummer. Deshalb ist dieses Zertifikat juristisch etwas wert — siehe Kapitel 8.2.

Die erste Prüfung kostet nichts und dauert dreißig Sekunden; die zweite kostet einen Gang zum Gemeindehaus. Beide sind nützlich, aber sie beweisen etwas völlig Verschiedenes. Ein Schloss-Symbol in deinem Browser sagt also nicht, dass die Firma dahinter in Ordnung ist — nur, dass der Name in der Adressleiste stimmt.

Was passiert, wenn eine einzige versagt

DigiNotar war eine niederländische Zertifizierungsstelle aus Beverwijk. Sie signierte unter anderem für die niederländische Regierung: DigiD, der Dienst, mit dem sich Niederländer beim Finanzamt anmelden, hing daran.

Am 19. Juli 2011 merkte die Firma, dass in ihre Systeme eingebrochen worden war. Sie schwieg. Am 10. Juli war bereits ein gefälschtes Zertifikat für *.google.com ausgestellt worden. Ende August lief ein Nutzer im Iran in eine Warnung von Chrome: Dieser Browser wusste, welche Zertifikate zu Google gehörten, und dieses war keines davon. Da flog alles auf. Mindestens 531 gefälschte Zertifikate waren erzeugt worden. Mit dem Google-Zertifikat war der Mailverkehr von geschätzt 300 000 iranischen Gmail-Nutzern mitgelesen worden — in einem Land, wo das Menschen ihre Freiheit kosten kann.

Die Browserhersteller warfen daraufhin alle DigiNotar-Zertifikate aus ihrer Liste. Damit war die Firma wertlos: Eine CA, der niemand mehr vertraut, verkauft nichts mehr. Am 20. September 2011, keinen Monat nach der Entdeckung, wurde DigiNotar für insolvent erklärt.

Eine einzige CA, die versagt, reißt nicht nur ihre eigenen Kunden mit, sondern alle. Das ist der Preis eines Systems, in dem 121 Wurzeln alle alles dürfen. Seitdem müssen CAs jedes ausgestellte Zertifikat in öffentliche Logbücher eintragen — Certificate Transparency — damit Google sehen kann, dass irgendwo ein Zertifikat für google.com erzeugt wurde, das Google nie bestellt hat. Diese Logbuchbeweise siehst du in der Demo stehen, wenn du ein Zertifikat einer echten Website nimmst.

Widerrufen: ungültig vor dem Enddatum

Ein privater Schlüssel kann durchsickern. Der Inhaber kann aufhören zu existieren. Dann muss das Zertifikat sofort ungültig sein und nicht erst bei notAfter. Das ist schwieriger, als es aussieht, denn das Zertifikat selbst ändert sich nicht — es liegt beim Angreifer auf der Festplatte und sieht immer noch perfekt aus. Es muss also etwas dazukommen, das sagt: Glaub das hier nicht mehr.

Weg	Wie	Problem
CRL certificate revocation list	Die CA veröffentlicht eine Liste mit widerrufenen Seriennummern. Dein Browser holt sich diese Liste und schaut nach, ob deine Seriennummer darin steht.	Die Liste ist groß und hinkt der Wirklichkeit hinterher.
OCSP online certificate status protocol	Dein Browser fragt pro Zertifikat live bei der CA nach: Gilt das hier noch?	Damit erzählst du der CA, welche Seiten du besuchst. Und wenn die CA nicht antwortet, machen Browser trotzdem weiter — sonst läge das halbe Web still.

Dieser zweite Einwand hat gewonnen. Let's Encrypt hat am 7. Mai 2025 die OCSP-Adressen aus seinen Zertifikaten entfernt und den Dienst am 6. August 2025 ganz abgeschaltet, mit dem Datenschutz als Grund. In der Demo siehst du es wieder: Bei einem Zertifikat einer echten Website steht zwar ein cRLDistributionPoints, aber keine OCSP-Adresse.

Die echte Lösung war am Ende einfacher: Mach Zertifikate so kurzlebig, dass Widerrufen kaum noch eine Rolle spielt. Ein Zertifikat, das nach ein paar Monaten von selbst abläuft, ist ein gestohlener Schlüssel, der von selbst schal wird. Deshalb erneuert ein Server sein Zertifikat heute automatisch, lange bevor es abläuft, ohne dass ein Mensch daran beteiligt ist.

Das ist Mathematik: Vertrauen als gerichteter Graph

Zeichne jedes Zertifikat als einen Pfeil: vom Issuer zum Subject. Was du bekommst, ist ein gerichteter Graph — Punkte mit Pfeilen dazwischen — und die Frage „Darf ich dieser Website glauben?“ wird zur Frage „Gibt es einen Weg von einem Punkt, dem ich schon vertraue, zu diesem Punkt?“. Genau um diese Art von Frage geht es in der Graphentheorie, demselben Fachgebiet, das ausrechnet, wie dein Routenplaner den kürzesten Weg findet.

So wird auch sofort sichtbar, wo es bei DigiNotar schiefging. In diesem Graphen gibt es 121 Punkte, an denen ein Weg beginnen kann, und von jedem dieser Punkte aus ist jeder andere Punkt erreichbar. Ein einziger geknackter Startpunkt genügt, um einen Weg zu irgendeinem beliebigen Namen zu fabrizieren. Die Mathematik sagt dir hier nicht, wie du etwas absicherst, sondern wie verwundbar die Form deines Systems ist — und das ist genauso nützlich.