Begriff
PKI (Public Key Infrastructure)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Ein Zertifikat allein reicht nicht. Du brauchst ein ganzes System, um Schlüssel zu verwalten. Eine PKI ist wie das Einwohnermeldeamt + Polizei + Passdruckerei zusammen. Sie regelt:
Erstellung: Wie beantragt man einen Ausweis?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: In der Firma: "Ich brauche VPN-Zugang." 1. Du generierst ein Key-Pair. 2. Die PKI (Software) signiert deinen Public Key. 3. Du bekommst das Cert auf deine Smartcard/YubiKey. 4. Wenn du entlassen wirst, setzt der Admin dein Cert auf die Sperrliste (CRL). Ab sofort kommst du nicht mehr rein.Verteilung: Wie kommt der Ausweis zum User?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: In der Firma: "Ich brauche VPN-Zugang." 1. Du generierst ein Key-Pair. 2. Die PKI (Software) signiert deinen Public Key. 3. Du bekommst das Cert auf deine Smartcard/YubiKey. 4. Wenn du entlassen wirst, setzt der Admin dein Cert auf die Sperrliste (CRL). Ab sofort kommst du nicht mehr rein.Prüfung: Wer darf prüfen?
Bei der Prüfung belegst du die Fakten, bevor du handelst: Was ist passiert, wo passiert es, seit wann, wie oft, mit welcher Auswirkung und mit welchem Nachweis? Erst danach entscheidest du den nächsten Schritt.- Sperrung: Was passiert, wenn ich meinen Ausweis verliere? (Revocation).
Ohne PKI sind Schlüssel nutzlos, weil man ihnen nicht vertrauen oder sie nicht managen kann. Das gesamte HTTPS-Internet ist eine riesige, weltweite PKI (Web PKI).
Merksatz: Die Gesamtheit aller Hardware, Software, Personen, Richtlinien und Verfahren, die benötigt werden, um digitale Zertifikate zu erstellen, zu verwalten, zu verteilen, zu nutzen, zu speichern und zu widerrufen.
In der Firma: "Ich brauche VPN-Zugang."
- Du generierst ein Key-Pair.
- Die PKI (Software) signiert deinen Public Key.
- Du bekommst das Cert auf deine Smartcard/YubiKey.
- Wenn du entlassen wirst, setzt der Admin dein Cert auf die Sperrliste (CRL). Ab sofort kommst du nicht mehr rein.
1. Revocation (CRL vs. OCSP)
Das schwerste Problem der PKI. Wie erfährt der Browser sofort, dass ein Zertifikat gestohlen wurde?
- CRL (Certificate Revocation List): Eine riesige Liste aller gesperrten Seriennummern. Browser müssen sie runterladen. (Langsam, Bandbreite!).
- OCSP (Online Certificate Status Protocol): Der Browser fragt die CA live: "Ist Cert X noch gut?" - "Ja.". (Privacy Problem: Die CA weiß, welche Seiten du besuchst).
- OCSP Stapling: Der Webserver holt sich die "Ja"-Antwort von der CA und liefert sie gleich mit dem Zertifikat an den Browser mit ("Hier ist mein Cert, und hier ist der Beweis von der CA, dass es noch frisch ist"). Beste Lösung.
2. Trust Anchors
Das Fundament. Dein Betriebssystem (Windows/macOS) oder Browser (Firefox) kommt mit ca. 150 vorinstallierten Root CAs (DigiCert, GlobalSign, Telekom...). Wenn eine CA nicht in dieser Liste ist, vertraut dein Computer ihr nicht. Malware versucht oft, eigene falsche Root-Certs zu installieren, um HTTPS aufzubrechen.
3. Key Ceremony
Wenn eine Root CA ihren Schlüssel erzeugt, ist das ein Hochsicherheits-Event. In einem Bunker. Mit Zeugen, Notaren, Videoaufzeichnung. Der Schlüssel wird in Shards geteilt und auf Smartcards gespeichert, die in verschiedenen Tresoren liegen. Denn: Wer den Root Key hat, kontrolliert das Internet.
1. Certificate Auto-Enrollment & ACME (Let's Encrypt)
Historisch war PKI manuell belastend: CSRs (Certificate Signing Requests) generieren, per E-Mail an Symantec schicken, 2 Tage warten, CRT installieren. Ein verpasster manueller Renewal führte oft zu Millionen-Dollar-Ausfällen (wie beim berüchtigten Zertifikats-Timeout von Epic Games / O2).
ACME (Automated Certificate Management Environment, RFC 8555) revolutionierte dies.
Der Certbot (Linux Daemon) generiert einen lokal temporären CSR. Die CA (Let's Encrypt) fordert einen Beweis (Challenge). Der Certbot platziert einen zufälligen Token unter http://deinedomain.com/.well-known/acme-challenge/. Die CA pingt die URL. Ist der Rückgabewert valide, beweist der Bot DNS-Ownership. Die CA rotzt asynchron das signierte x.509 Result via JSON RPC zurück, und Nginx macht einen Reload. Laufzeit: 4 Sekunden. Resultat: Zertifikate können gefahrlos auf knappe $90$-Tage Livetimes gestutzt werden, was das Risiko von kompromittierten Keys und CRL-Listen massiv verringert.
2. X.509 Struktur & ASN.1 Parsing Exploits
Das Fundament jedes Zertifikats ist der X.509 Standard, beschrieben in der Abstract Syntax Notation One (ASN.1). Es gleicht einem stark veralteten, binären XML aus den 80er Jahren.
Die Parse-Komplexität von Feldern (Subject Alternative Name (SAN), Basic Constraints, Extended Key Usage) in C-Bibliotheken (OpenSSL) erzeugte jahrzehntelang katastrophale Memory-Corruption (Buffer Overflows).
Ein klassischer Logic-Bug ist der Null-Byte-Attack: Der Hacker beantragt legit hacker.com\0.paypal.com. Eine schlampige C-Library stoppt das String-Lesen beim C-String Terminator \0 und validiert wildlings hacker.com, während der Browser aber paypal.com aus der SAN extrahiert. Ergebnis: Ein legitimes SSL-Zertifikat für PayPal in Hacker-Händen. Moderne TLS-Libs (wie Rustls) lehnen solche ASN.1 Missgeburten als Hard-Fault ab, um Parser-Injection komplett zu evakuieren.
3. Certificate Transparency (CT Logs)
Die ultimative Schwachstelle einer globalen PKI: Das "Weakest Link" Theorem. Über 150 Root CAs in deinem Browser dürfen theoretisch jedes beliebige Zertifikat auf der Welt legal ausstellen. Wenn der persische Geheimdienst eine lokale Unter-CA hackt und google.com Zertifikate generiert (wie beim DigiNotar Hack 2011), bemerkt das die restliche Welt nicht, da die Mathematik validiert.
Google löste das durch Certificate Transparency.
Jede CA ist von Apple/Google rigoros dazu gezwungen, jedes ausgestellte Zertifikat sofort öffentlich in einen kryptographisch unveränderbaren Append-Only-Merkle-Tree (SCT-Log) zu spammen. Chrome lehnt Zertifikate hart ab, wenn der Server beim Handshake keinen validierten Signed Certificate Timestamp (SCT) vorlegt (Beweis für die Publikation). So kann das Ops-Team von Google APIs sofort via Alert-System sehen: "Eine kasachische CA hat soeben ein google.com Zertifikat geprägt – das war nicht von uns!" und die Fake-CA augenblicklich blockieren.
Quick-Check
Web of Trust (PGP)?
Der Gegenentwurf zur PKI. Keine zentrale Autorität (CA). User zertifizieren sich gegenseitig ("Ich vertraue Max, und Max vertraut Moritz, also vertraue ich Moritz"). Hat sich im Web nicht durchgesetzt (nicht skalierbar).RA (Registration Authority)?
Der "Schalterbeamte". Die RA prüft den Ausweis, darf aber keine Zertifikate drucken. Sie sagt der CA: "Alles okay, druck mal." (Aufgabentrennung).SSH und PKI?
SSH nutzt standardmäßig keine PKI (sondern "Trust on First Use" - TOFU). Man kann aber SSH Certificates nutzen (mit eigener CA), was in großen Firmen (Netflix, Facebook) Standard ist, um Access Management zu skalieren.