Grundwissen: Asymmetrische Kryptografie erklärt, Teil 3

Wenn man ein fehlerhaftes Zertifikat widerrufen muss, blättert von der Public-Key-Infrastruktur schnell der Lack ab. Wir erklären, an welchen Stellen es klemmt.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht
,
Lesezeit: 19 Min.
Inhaltsverzeichnis

Zertifikate sind das primäre Bollwerk gegen Betrug und Überwachung im Internet. In den beiden ersten Teilen dieser Reihe (Teil 1 und Teil 2) haben wir erklärt, wie man ein Schlüsselpaar generiert und dann über einen "Certificate Signing Request" (CSR) eine Zertifizierungsstelle (Certification Authority, CA) um ein Zertifikat bittet.

Das belegt nun die Authentizität der eigenen Website und erlaubt, die Kommunikation mit den Webseitenbesuchern zu verschlüsseln. Das klappt – ganz wichtig – unabhängig von der CA. Die erfährt nicht, welche Nutzer die Website besuchen, und kann auch komplett ausfallen, ohne dass dies die Sicherheit der Website beeinträchtigt. Zumindest, wenn man nicht gerade ein neues Zertifikat benötigt.

Mehr zum Thema Verschlüsselung

Allerdings hat das etablierte Zertifikatswesen im Web durchaus mit diversen Problemen zu kämpfen. Besonders deutlich zeigen sich die Mängel, wenn es an den Widerruf geht: Was, wenn der private Schlüssel des Zertifikats in falsche Hände geraten ist oder man das zumindest befürchten muss? Dann bräuchte man ein System, um alle potenziellen Webseitenbesucher zu informieren, möglichst sofort. Denn solange sie dem kompromittierten Zertifikat noch vertrauen, könnten Diebe des privaten Schlüssels Fake-Seiten bauen, die nicht nur täuschend echt aussehen und scheinbar unter der korrekten URL firmieren, sondern auch vom Browser klaglos akzeptiert werden.