Zertifikate: Wem gehört eigentlich dieser Schlüssel?

22.07.2026 · 6 Min. Lesezeit

Am Ende des letzten Artikels haben wir eine Frage offengelassen, die auf den ersten Blick wie ein Detail wirkt, sich bei genauerem Hinsehen aber als der wohl praktischste Knackpunkt der gesamten asymmetrischen Kryptographie entpuppt: Woher weiß man eigentlich, dass ein bestimmter öffentlicher Schlüssel wirklich der Person oder Organisation gehört, die er zu gehören vorgibt? Die gesamte Mathematik, die wir in den vorherigen Artikeln kennengelernt haben, kann diese Frage nämlich gar nicht beantworten. Sie stellt lediglich sicher, dass eine Signatur zu einem bestimmten öffentlichen Schlüssel passt – nicht aber, wem dieser Schlüssel tatsächlich gehört. Und genau an diesem Punkt setzt das Konzept der Zertifikate an, mit dem wir uns in diesem Artikel beschäftigen wollen.

Das Problem an einem konkreten Beispiel

Stell dir vor, du möchtest die Webseite deiner Bank aufrufen, um eine Überweisung zu tätigen. Damit dein Browser die Verbindung verschlüsseln kann, benötigt er zunächst den öffentlichen Schlüssel des Servers deiner Bank, den er über die Internetverbindung erhält. Nun stell dir aber vor, ein Angreifer sitzt irgendwo zwischen dir und dem tatsächlichen Server deiner Bank – etwa weil du in einem öffentlichen WLAN unterwegs bist, das der Angreifer kontrolliert – und schickt dir stattdessen seinen eigenen öffentlichen Schlüssel, gibt sich dabei aber als deine Bank aus. Ohne eine zusätzliche Absicherung könntest du diese Täuschung nicht erkennen. Du würdest deine Verbindung mit dem Schlüssel des Angreifers verschlüsseln, in dem festen Glauben, mit deiner Bank zu sprechen, während der Angreifer in Wahrheit alles mitlesen und sogar unbemerkt verändern könnte, bevor er die Daten an die echte Bank weiterreicht. Diese Art von Angriff nennt man in der Fachsprache einen Man-in-the-Middle-Angriff, weil sich der Angreifer buchstäblich in die Mitte der Verbindung setzt. Die reine asymmetrische Kryptographie allein, so elegant sie auch ist, schützt dich davor nicht – sie prüft schließlich nur, ob zusammengehörige Schlüssel benutzt wurden, nicht aber, wem diese Schlüssel wirklich gehören.

Die Idee: eine dritte Partei, der man vertraut

Die Lösung für dieses Problem folgt einem Prinzip, das dir aus dem echten Leben bereits vertraut ist. Wenn du dich mit deinem Personalausweis ausweist, vertraut dein Gegenüber diesem Dokument nicht deshalb, weil er dich persönlich kennt, sondern weil er der ausstellenden Behörde vertraut, die deine Identität vorab sorgfältig geprüft und mit ihrer eigenen Autorität bestätigt hat. Genau dieses Prinzip überträgt man in der digitalen Welt auf sogenannte Zertifizierungsstellen, im Englischen “Certificate Authorities” oder kurz CAs genannt. Eine solche Zertifizierungsstelle ist eine Organisation, deren Aufgabe darin besteht, die Identität von Personen, Firmen oder Servern zu überprüfen und diese Identität anschließend fest mit einem öffentlichen Schlüssel zu verknüpfen. Diese Verknüpfung geschieht in Form eines sogenannten Zertifikats, und hier schließt sich der Kreis zum vorherigen Artikel wieder: Ein Zertifikat ist im Grunde nichts anderes als ein Dokument, das die Angabe “dieser öffentliche Schlüssel gehört zu dieser Identität” enthält, und dieses Dokument wird von der Zertifizierungsstelle mit ihrem eigenen privaten Schlüssel digital signiert – genau nach dem Verfahren, das wir bereits kennen.

Möchte also der Server deiner Bank seinen öffentlichen Schlüssel vertrauenswürdig verbreiten, lässt der Betreiber sich zunächst bei einer anerkannten Zertifizierungsstelle registrieren. Diese prüft, in unterschiedlicher Tiefe je nach Art des Zertifikats, ob die Bank tatsächlich die Kontrolle über die entsprechende Domain besitzt, und stellt anschließend ein Zertifikat aus, das den öffentlichen Schlüssel der Bank fest mit deren Namen verknüpft und mit dem privaten Schlüssel der Zertifizierungsstelle signiert ist. Wenn dein Browser sich nun mit dem Server deiner Bank verbindet, bekommt er nicht mehr nur einen nackten öffentlichen Schlüssel präsentiert, sondern dieses vollständige, signierte Zertifikat.

Wie dein Browser einem Zertifikat vertraut

An dieser Stelle könnte man einwenden, dass wir das ursprüngliche Problem doch nur eine Ebene weiter verschoben haben: Um die Signatur der Zertifizierungsstelle zu prüfen, benötigt dein Browser ja wiederum deren öffentlichen Schlüssel – und woher weiß er, dass dieser Schlüssel echt ist? Diese berechtigte Frage löst sich dadurch auf, dass eine überschaubare Anzahl besonders vertrauenswürdiger Zertifizierungsstellen, sogenannte Root-Zertifizierungsstellen, mit ihren öffentlichen Schlüsseln bereits fest in deinem Betriebssystem oder Browser hinterlegt sind, wenn du diesen installierst. Diese sogenannten Root-Zertifikate wurden nach sehr strengen Prüfverfahren in die Software aufgenommen und bilden den sogenannten Vertrauensanker: die Stelle, an der die Prüfkette beginnt und der man schlicht vertrauen muss, ähnlich wie man in der analogen Welt letztlich dem Staat vertrauen muss, der die Ausweisdokumente ausstellt.

In der Praxis stellen diese Root-Zertifizierungsstellen aus Sicherheitsgründen meist nicht direkt selbst die Zertifikate für einzelne Webseiten aus, sondern signieren stattdessen die Zertifikate weiterer, sogenannter Zwischenzertifizierungsstellen, die wiederum die eigentlichen Zertifikate für Webseiten wie die deiner Bank ausstellen. Es entsteht dadurch eine regelrechte Kette: Das Zertifikat deiner Bank wurde von einer Zwischenzertifizierungsstelle signiert, deren eigenes Zertifikat wiederum von einer Root-Zertifizierungsstelle signiert wurde, deren öffentlicher Schlüssel bereits vertrauenswürdig in deinem Browser hinterlegt ist. Man spricht deshalb auch von einer Vertrauenskette oder “Chain of Trust”. Verbindet sich dein Browser mit dem Server deiner Bank, prüft er diese gesamte Kette Glied für Glied: Passt die Signatur des Bankzertifikats zum öffentlichen Schlüssel der Zwischenzertifizierungsstelle? Passt wiederum deren Signatur zum öffentlichen Schlüssel der Root-Zertifizierungsstelle? Und ist diese Root-Zertifizierungsstelle eine, der der Browser von Haus aus vertraut? Nur wenn jedes einzelne Glied dieser Kette stimmig ist, zeigt dein Browser die Verbindung als vertrauenswürdig an, meist erkennbar an dem kleinen Schloss-Symbol in der Adresszeile.

Kehren wir kurz zu unserem Angreifer aus dem WLAN zurück: Versucht er, dir seinen eigenen öffentlichen Schlüssel unterzuschieben, indem er sich als deine Bank ausgibt, müsste er dafür auch ein gültiges, auf den Namen der Bank ausgestelltes Zertifikat vorlegen können, das von einer im Browser als vertrauenswürdig hinterlegten Zertifizierungsstelle signiert wurde. Ohne Zugriff auf den privaten Schlüssel einer solchen Zertifizierungsstelle kann er ein solches Zertifikat aber nicht fälschen – genau hier liegt der eigentliche Schutz, den Zertifikate bieten.

Was ein Zertifikat garantiert – und was nicht

Ein verbreitetes Missverständnis lohnt sich an dieser Stelle noch auszuräumen: Das Schloss-Symbol in deinem Browser und ein gültiges Zertifikat bedeuten ausschließlich, dass die Verbindung verschlüsselt ist und dass du tatsächlich mit dem Server sprichst, dessen Namen im Zertifikat steht – mehr nicht. Es bedeutet ausdrücklich nicht, dass die betreffende Webseite seriös, vertrauenswürdig oder frei von betrügerischer Absicht ist. Auch Betrüger können sich, sofern sie die Kontrolle über eine entsprechende Domain nachweisen können, ganz legitim ein gültiges Zertifikat für ihre eigene Phishing-Webseite ausstellen lassen; das Schloss-Symbol würde dann trotzdem erscheinen, weil die Verbindung zu genau dieser Domain tatsächlich verschlüsselt und authentisch ist – nur eben authentisch zu einer betrügerischen Seite. Ein Zertifikat bestätigt also die Identität eines Kommunikationspartners, nicht dessen Absichten.

Ausblick

Damit haben wir nun die vier zentralen Bausteine kennengelernt, aus denen sich sichere Kommunikation im Internet zusammensetzt: symmetrische Verschlüsselung für die eigentlichen Daten, asymmetrische Verschlüsselung zum sicheren Austausch der dafür nötigen Schlüssel, digitale Signaturen zur Überprüfung von Echtheit und Unversehrtheit, und Zertifikate, um Schlüssel überhaupt erst vertrauenswürdig mit einer Identität zu verknüpfen. Wie genau all diese Bausteine zusammenspielen, wenn du im Browser eine “https”-Adresse aufrufst und im Hintergrund innerhalb von Sekundenbruchteilen eine sogenannte TLS-Verbindung aufgebaut wird, schauen wir uns gerne in einem weiteren Artikel dieser Reihe im Detail an.