Was ist eine Public-Key-Infrastruktur?

Das Problem, das eine PKI löst

Asymmetrische Verschlüsselung arbeitet mit Schlüsselpaaren. Was mit dem öffentlichen Schlüssel verschlüsselt wird, kann nur der passende private Schlüssel lesen, und was mit dem privaten Schlüssel signiert wird, lässt sich mit dem öffentlichen prüfen. Den öffentlichen Schlüssel darf jeder kennen. Offen bleibt aber eine entscheidende Frage: Woher weißt du, dass der öffentliche Schlüssel, den dir ein Server schickt, wirklich zu deiner Bank gehört und nicht zu einem Angreifer dazwischen?

Die PKI beantwortet diese Frage mit einer vertrauenswürdigen dritten Stelle. Eine Zertifizierungsstelle prüft, wem ein Schlüssel gehört, und bestätigt das mit ihrer digitalen Signatur in einem Zertifikat. Wer der Zertifizierungsstelle vertraut, kann damit jedem Zertifikat vertrauen, das sie ausgestellt hat, ohne den Inhaber selbst zu kennen.

Aufbau einer PKI: die Bausteine

Eine PKI ist kein einzelnes Programm, sondern ein Verbund aus Rollen, Diensten und Regeln. Die Bezeichnungen stammen überwiegend aus dem Standard X.509, den das Internet-Dokument RFC 5280 für den Einsatz im Netz beschreibt:

• Zertifizierungsstelle (CA)

  Signiert Zertifikate mit ihrem privaten Schlüssel und bürgt damit für die Zuordnung von Name und Schlüssel. In einer Hierarchie gibt es eine Stamm-CA und darunter ausstellende CAs.

• Registrierungsstelle (RA)

  Prüft die Identität des Antragstellers, bevor die CA signiert. In kleinen PKIs ist das oft ein Genehmigungsschritt oder eine Berechtigung auf einer Zertifikatvorlage.

• Sperr- und Validierungsdienst

  Veröffentlicht Sperrlisten (CRL) oder beantwortet Statusanfragen per OCSP, damit Clients erkennen, ob ein Zertifikat vorzeitig zurückgezogen wurde.

• Verzeichnis

  Ein erreichbarer Ort, an dem CA-Zertifikate und Sperrlisten liegen, etwa ein Webserver oder das Active Directory.

• Richtlinien

  Die Certificate Policy und das Certification Practice Statement legen fest, wer welche Zertifikate wofür bekommt, wie geprüft wird und wie lange sie gelten.

• Schlüsselschutz

  Die privaten Schlüssel der CAs liegen idealerweise in einem Hardware-Sicherheitsmodul (HSM), aus dem sie sich nicht kopieren lassen.

• Zertifikatsinhaber

  Server, Geräte, Benutzer oder Anwendungen, die ein Zertifikat beantragen und ihren privaten Schlüssel selbst verwahren.

Vom Schlüsselpaar zum Zertifikat

Am Anfang steht ein Schlüsselpaar: Der private Schlüssel bleibt auf dem System, das ihn erzeugt hat, der öffentliche geht zusammen mit einem Antrag, dem Certificate Signing Request (CSR), an die Zertifizierungsstelle. Die Stelle prüft den Antrag, signiert ihn mit ihrem eigenen privaten Schlüssel und gibt ein Zertifikat zurück. Das Zertifikat ist damit eine beglaubigte Zuordnung eines Namens zu einem öffentlichen Schlüssel, versehen mit Gültigkeitszeitraum, Aussteller, Seriennummer und einer Angabe, wofür der Schlüssel benutzt werden darf.

Wichtig ist dieser Verwendungszweck. Ein Zertifikat für Serverauthentifizierung taugt nicht automatisch für Codesignatur oder für die Anmeldung mit Smartcard. Wer Vorlagen zu großzügig konfiguriert, verteilt Schlüssel, die mehr dürfen als nötig, und schafft damit genau die Angriffswege, die die PKI verhindern soll.

Ein-, zwei- oder dreistufige Hierarchie

Beim Aufbau einer PKI ist die wichtigste Entscheidung die Zahl der Ebenen. Die Stamm-CA ist der Vertrauensanker, ihr Zertifikat liegt im Vertrauensspeicher jedes Clients. Fliegt ihr privater Schlüssel auf, musst du auf jedem Gerät den Anker austauschen. Fliegt dagegen der Schlüssel einer ausstellenden CA auf, sperrst du deren Zertifikat und baust sie neu auf. Deshalb wird die Stamm-CA möglichst selten benutzt.

Im zweistufigen Aufbau signiert die Stamm-CA nur die Zertifikate der ausstellenden CAs und ihre eigene Sperrliste, danach wird sie ausgeschaltet und weggeschlossen. Den Alltag erledigen die ausstellenden CAs. Auch das Stammzertifikat hat ein Ablaufdatum, meist viele Jahre in der Zukunft. Trag es in dieselbe Liste ein, in der die Verlängerung von Domains und Serverzertifikaten steht, sonst fällt eines Tages alles gleichzeitig aus.

Wie ein Client ein Zertifikat prüft

Wenn dein Browser eine HTTPS-Verbindung aufbaut oder ein Rechner sich per Zertifikat im WLAN anmeldet, prüft die Gegenseite das Zertifikat in mehreren Schritten. Scheitert einer davon, wird die Verbindung abgelehnt oder eine Warnung angezeigt:

1. 1

   Kette bilden

   Vom Zertifikat über die ausstellende CA bis zu einem Stammzertifikat, das im eigenen Vertrauensspeicher liegt. Fehlt ein Zwischenzertifikat, bricht die Prüfung hier ab.

2. 2

   Signaturen prüfen

   Jedes Glied der Kette muss korrekt vom nächsthöheren signiert sein.

3. 3

   Gültigkeit prüfen

   Das aktuelle Datum muss zwischen Beginn und Ende der Gültigkeit liegen, bei allen Zertifikaten der Kette.

4. 4

   Name und Zweck prüfen

   Der aufgerufene Name muss im Zertifikat stehen, und der Verwendungszweck muss zum Einsatz passen.

5. 5

   Sperrstatus prüfen

   Über Sperrliste oder OCSP wird geklärt, ob das Zertifikat vorzeitig zurückgezogen wurde.

Die Adressen für Sperrliste und OCSP stehen im Zertifikat selbst. Der häufigste Ausfall in diesem Bereich hat nichts mit Kryptografie zu tun: Die Sperrliste läuft ab, weil ihr Veröffentlichungsweg nicht mehr funktioniert, und plötzlich lehnen Clients gültige Zertifikate ab. Genauso oft steht im Zertifikat eine interne Adresse, die Geräte im Homeoffice oder Partner von außen gar nicht erreichen. Bei öffentlichen Zertifikaten verliert OCSP übrigens an Bedeutung, Let's Encrypt etwa hat seinen OCSP-Dienst 2025 eingestellt und setzt nur noch auf Sperrlisten.

Öffentliche und interne PKI

Die Zertifikate, die dein Browser bei Websites akzeptiert, stammen aus der öffentlichen PKI. Deren Stammzertifikate liefern Browser- und Betriebssystemhersteller mit, und die Stellen müssen dafür die Regeln des CA/Browser Forums einhalten. Dazu gehört auch die maximale Laufzeit: Nach dem 2025 beschlossenen Zeitplan sinkt sie für öffentliche TLS-Zertifikate seit März 2026 in Stufen, von früher 398 Tagen bis auf 47 Tage ab März 2029. Ohne automatische Erneuerung, etwa über das ACME-Protokoll, ist das nicht mehr zu bewältigen.

Eine interne PKI betreibst du selbst, unter Windows meist mit den Active Directory-Zertifikatdiensten. Sie stellt Zertifikate für Dinge aus, die nur deine eigenen Geräte betreffen: Anmeldung am WLAN per 802.1X, VPN-Zugänge, Smartcard-Anmeldung, interne Webserver, Geräte im Mobile Device Management oder signierte Skripte. Gruppenrichtlinien lassen Computer und Konten ihre Zertifikate dort selbst anfordern und rechtzeitig erneuern. Wer automatisch ausrollt, braucht trotzdem ein Inventar, sonst kann beim nächsten Wechsel des Signaturverfahrens niemand sagen, welche Systeme noch alte Zertifikate benutzen.