Was ein Zertifikat beweist

Zähl die Stellen, an denen dieser Kurs „nur über HTTPS“ gesagt hat. Das Session-Cookie trägt Secure, also sendet ein Browser es über HTTPS und sonst nirgendwohin. Sein Name beginnt mit __Host-, was ein Browser nur aus einer HTTPS-Antwort annimmt. Basic-Zugangsdaten sind das Passwort in Base64. Ein Bearer-Token funktioniert für jeden, der es hat. Jedes davon ist nur sicher, wenn niemand zwischen Client und Server die Anfrage lesen kann, und nur, wenn am anderen Ende der richtige Server sitzt.

HTTP with Python hat gezeigt, dass HTTPS HTTP in TLS ist und dass ein Standard-TLS-Kontext das Zertifikat des Servers und seinen Namen prüft. Diese Lektion fragt, woraus diese Prüfung besteht. Was sieht sich ein Client an, bevor er ein Passwort sendet?

Ein Name, ein Schlüssel, ein Aussteller und zwei Daten

Ein Server, der TLS spricht, legt ein Zertifikat vor. Hier sind fünf Zeilen des Testzertifikats, das dieses Kapitel verwendet, so wie das Werkzeug openssl sie ausgibt:

Issuer: O=Python Land course tests, CN=TEST ONLY Python Land Web Security course authority
Not Before: Nov  1 00:00:00 2026 GMT
Not After : Nov  1 00:00:00 2046 GMT
Subject: O=Python Land course tests, CN=TEST ONLY reading
DNS:reading.example, DNS:app.reading.example, DNS:notes.reading.example, DNS:localhost, IP Address:127.0.0.1

Die letzte Zeile listet die Namen auf, für die das Zertifikat gilt. Die Datei enthält außerdem einen öffentlichen Schlüssel, der hier nicht gezeigt wird. Ein Zertifikat verbindet also vier Dinge: einen Namen, einen öffentlichen Schlüssel, einen Aussteller, der die Aussage signiert hat, und den Zeitraum, in dem sie gilt. Diese Testdatei gilt zwanzig Jahre. Ein Zertifikat von einem öffentlichen Aussteller hält etwa ein Jahr oder kürzer.

Ein Zertifikat ist öffentlich. Der Server sendet es an jeden Client, der sich verbindet, und jeder kann es kopieren. Was einem Betrüger fehlt, ist der private Schlüssel, der zum öffentlichen Schlüssel in der Datei gehört. Während des TLS-Handshakes beweist der Server, dass er diesen privaten Schlüssel besitzt, ohne ihn preiszugeben. Ein kopiertes Zertifikat ohne den Schlüssel beweist nichts.

Signiert von jemandem, dem du schon vertraust

Jeder kann eine Datei schreiben, in der steht: „dieser Schlüssel gehört reading.example“. Ein Zertifikat zählt, weil ein Aussteller es signiert hat. Ein Aussteller heißt auch Zertifizierungsstelle (certificate authority); diese Lektion sagt Aussteller.

In Kapitel 2 hast du eine Nachricht mit einem HMAC-Tag geschützt. Ein Schlüssel hat den Tag erzeugt, und derselbe Schlüssel hat ihn geprüft. Das funktioniert, wenn beide Seiten dieselbe Partei sind oder ein Geheimnis teilen. Hier kann es nicht funktionieren. Jeder Client der Welt muss ein Zertifikat prüfen können, und wer einen HMAC-Tag prüfen kann, kann auch einen erzeugen.

Die Signatur eines Ausstellers ist eine andere Art von Signatur, eine Public-Key-Signatur. Der Aussteller signiert mit einem privaten Schlüssel, den er nie teilt. Jeder kann die Signatur mit dem öffentlichen Schlüssel des Ausstellers prüfen, und das Prüfen gibt keine Macht zum Signieren. Dieser Kurs baut solche Signaturen nicht; es genügt zu wissen, welche Eigenschaft sie haben, die einem Tag mit Schlüssel fehlt.

Bleibt eine Frage: Woher bekommt der Client den öffentlichen Schlüssel des Ausstellers? Er beginnt mit einer Liste von Ausstellern, denen er vertraut, installiert mit dem Betriebssystem oder dem Browser. Die Prüfung endet an dieser Liste. Ein Zertifikat von einem Aussteller, der nicht darauf steht, beweist diesem Client nichts, so korrekt es auch aussieht.

Drei Prüfungen

Bevor ein Client auch nur ein Byte einer Anfrage sendet, macht er drei Prüfungen am Zertifikat:

1. Aussteller. Wurde es von einem Aussteller auf meiner Liste signiert?

2. Name. Gilt es für den Namen, nach dem ich gefragt habe?

3. Datum. Liegt heute innerhalb seines Zeitraums?

Hier ist ein Modell der drei Prüfungen. Es ist ein Modell: Ein echter Client prüft Signaturen, wo dieser Code Namen vergleicht. Daten in der Form Jahr, Monat, Tag lassen sich als Text korrekt vergleichen, also hält das Modell sie als Strings. Führ es aus:

Die ersten drei Aufrufe geben accepted, refused: wrong name und refused: unknown issuer aus. Jede Ablehnung nennt eine Prüfung. Die Namensprüfung ist die, die man vergisst: Ein vertrauenswürdiger Aussteller signiert Zertifikate für Millionen von Sites, also sagt „von einem vertrauenswürdigen Aussteller signiert“ nichts, solange nicht auch der Name passt.

Was ein Zertifikat nicht sagt

Ein gültiges Zertifikat sagt dir, dass du mit einem Server sprichst, der den Schlüssel für den Namen besitzt, nach dem du gefragt hast, und dass ein Aussteller, dem du vertraust, das bestätigt hat. Sonst sagt es dir nichts. Es sagt nicht, wer die Site betreibt, was die Site mit einem Passwort macht oder ob ihr Code sicher ist. Bei der üblichen Art von Zertifikat prüft ein Aussteller, dass der Antragsteller den Namen kontrolliert, und mehr prüft er nicht. Manche Zertifikate nennen außerdem eine Organisation. Ein Client sieht sich das nicht an: Er prüft den Namen. Eine Site, die Passwörter als Klartext speichert, kann ein völlig gültiges Zertifikat haben.

Noch eine Grenze, nur zum Wiedererkennen. Ein Aussteller kann ein Zertifikat vor seinem Enddatum zurückziehen, was Widerruf (revocation) heißt. Pythons Standardkontext prüft das nicht.

Du kannst jetzt sagen, was ein Client prüft. Noch macht nichts in deinem Projekt diese Prüfungen. Die nächste Lektion baut das Objekt, das sie macht.