Eigenständige Zertifizierungsstelle aufsetzen

Februar 23, 2009 by Michael Fritz
Filed under: Lernschmiede, Security, Windows, Windows Server 2008

Dieser Artikel bezieht sich auf das Lernschmiede Kernnetzwerk. Ziel ist es, eine eigenständige Stammzertifizierungsstelle in simulierten WAN aufzusetzen. Benötigte virtuelle Maschine: Internet. und Clt1.home

“Jetzt fängt der auch noch mit Zertifikaten an…”

Wenn Sie über das Grundsystem der Zertifikate Bescheid wissen, können Sie gleich hier hin springen. Mit Zertifikatsstoff kann man ganze Unterrichtswochen füllen und das auch noch ziemlich in die Tiefe. Die mangelnde Vereinfachung des komplexen Stoffs für den Endbenutzer ist aus meiner Sicht einer der Hauptgründe dafür, dass sich Zertifikate in der breiten IT und insbesondere bei der Mailverschlüsselung bisher nicht durchsetzen konnten. An dieser Stelle eine verkürzte, nichttechnische Einführung…

Was sind Zertifikate?

Zertifikate sind digitale Ausweisdokumente mit folgendem Zweck:

Nachweis der Identität des Zertifikatsinhabers (Authentizität)
Verschlüsselung des Datenstroms (Vertraulichkeit)

Auch Verfügbarkeit und Integrität sind Zertifikatsthemen, sind aber hier nicht Thema. Allein diese beiden Zwecke werfen viele Fragen bezüglich des Implementierungsrahmens auf:

Wer oder was stellt Zertifikate aus?
Wie funktioniert die Verschlüsselung?
Wie läuft die Identitätsprüfung ab?
Wie lange sind Zertifikate gültig?
Welche Zwecke deckt das Zertifikat ab?
Wie hoch sind die Kosten?

Grundsätzliches in Kürze

Eine Zertifikatsinfrastruktur benötigt einen technischen Rahmen. Dieser Rahmen wird als PKI (Public Key Infrastructure) bezeichnet und enthält ein Sammelsurium an Komponenten für deren Umsetzung. Herzstück der PKI ist die CA (Certification Authority) Eine Zertifizierungsstelle, wie sie auf deutsch heißt, ist für die Ausstellung / Ausgabe der Zertifikate zuständig. Windows Serversysteme haben eine Zertifizierungsstelle schon an Bord, die als Rolle oder Funktion installiert wird.

Symmetrisch oder Asymmetrisch?

Die Verschlüsselung erfolgt asymmetrisch. Nicht abschrecken lassen! Die symmetrische Verschlüsselung ist jedem bekannt. Sender und Empfänger nutzen jeweils einen / den gleichen Schlüssel. Beide Parteien müssen diesen Schlüssel kennen, damit wird der Datenstrom ver- und entschlüsselt. Ein populäres Beispiel ist die WLAN-Verschlüsselung, hier muss der Schlüssel sowohl auf dem WLAN-Router, als auch auf dem eigenen Rechner eingetragen werden. Wird gerne auch als “Passphrase” bezeichnet.

Die asymmetrische Verschlüsselung nutzt hingegen zwei verschiedene Schlüssel, die sich gegeneinander auflösen. Wenn mit Schlüssel 1 etwas verschlüsselt wird, bekommt man es mit Schlüssel 2 wieder auf – und zwar _nur_ mit diesem. Andersherum funktioniert es genauso. Mathematiker sind wirklich schlaue Füchse.

Dieses Schlüsselpaar besteht aus einem öffentlichen Schlüssel, den jeder einsehen kann / darf / muss und einem privaten Schlüssel, der geheim bleibt. Ein Datenstrom wird mit dem öffentlichen Schlüssel des Gegenübers verschlüsselt und der kriegt die Pakete mit seinem privaten Schlüssel wieder auf. Der öffentliche Schlüssel steht in einem Zertifikat und ist das zentrale Element. (Hybride Verschlüsselung lassen wir hier weg)

Weiterhin steht eine Seriennummer, der Name des Zertifikatsinhabers und auch der Name der ausstellenden CA drin.

Vertrauensfrage

Während die Verschlüsselung technisch gut gelöst werden kann, ist die Vertrauensfrage das zentrale Problem die größte Herausforderung einer Zertifikatsinfrastruktur.

Nehmen wir an, Sie rufen eine Bankingwebsite auf und bekommen ein Zertifikat präsentiert. Dieses Zertifikat besagt nun folgendes:

Das Zertifikat für “Banking.Lernschmiede.de” wurde von der Zertifizierungsstelle “Elitetrainer-CA” ausgestellt. Mit dem öffentlichen Schlüssel des Zertifikats würden Sie den (Teil) Datenstrom verschlüsseln und die Lernschiede Bank entschlüsselt die Daten wieder mit deren privatem Schlüssel.

Kennen Sie die Eliterainer-CA?
Wer sagt Ihnen, dass die Überprüfung der Bankidentität ordnungsgemäß war?
Sind Sie sicher, dass es sich um die Website der Bank handelt und nicht um einen Betrüger?

Sie vertrauen halt darauf! Mit diesem Problem kämpft man nicht nur in virtuellen Umgebungen, sondern auch in der Realität! Achten Sie ruhig mal auf das Zertifikat indem Sie z.B. auf das “Schloss-Symbol” im Browser beim Aufruf einer HTTPS-Seite klicken.

Um Gewissheit zu erlangen, stehen zwei Möglichkeiten im Raum:

Sie rufen bei der Bank an, und fragen nach, ob der Fingerabdruck des Bankzertifikats mit dem identisch ist, welches Sie auf Ihrem Bildschirm angezeigt bekommen. Ein Fingerabdruck ist eine elektronische Prüfsumme, die mathematisch eindeutig sein sollte und über das Zertifikat selbst gebildet wird.
Sie vertrauen der Zertifizierungsstelle, die das Zertifikat ausgegeben hat, dass sie ihren Job ordentlich gemacht hat.

Trau – Schau –Wem?

Normalerweise ist Letzteres der Fall. PKIs sind so aufgebaut, das wenn der Benutzer einer CA vertraut, so tut er dies er gleichzeitig den Zertifikaten, die diese ausgegeben hat. Man spricht hier von einer Zertifikatskette. Die Zertifizierungsstelle (CA) an der Spitze wird bisweilen auch als “Root-CA” (Wurzel) bezeichnet. Diese kann Zertifikate direkt an Endbenutzer ausgeben, oder aber Zertifikate an untergeordnete CAs ausstellen (signieren) – die wiederum Zertifikate ausstellen dürfen usw. Wie gesagt, eine Zertifizierungskette - entscheidend ist das persönliche Vertrauen.

Wer ist vertrauenswürdig

Noch da? Was wissen wir bis jetzt?

Zertifikate sind Identitätsdokumente, für Verschlüsselung zuständig und werden von Zertifizierungsstellen ausgestellt (CA=Zertifizierungsstelle)
Alle Komponenten einer Zertifikatsinfrastruktur zusammen nennt man PKI – Public Key Infrastructure
Die Verschlüsselung ist asymmetrisch und basiert auf einem öffentlich / privatem Schlüsselpaar
Der öffentliche Schlüssel steckt im Zertifikat, der private Schlüssel ist geheim (auf der Festplatte oder einem anderen Datenspeicher)
Das Problem ist das Vertrauen – Wer steckt wirklich hinter dem Zertifikat?
Wer der CA vertraut, vertraut auch deren Zertifikaten und untergeordneten Zertifizierungsstellen = Zertifikatskette

Bleibt eine letzte Frage: “Wie lege ich als Benutzer fest, wem ich vertraue und wem nicht?” In Windows übernimmt dies der sogenannte “Zertifikatsspeicher”, in dem alle Zertifikate, die der Rechner kennt, hinterlegt werden. Es gibt mehrere Zertifikatsspeicher. Der entscheidende Speicher ist in diesem Fall als “vertrauenswürdige Stammzertifizierungsstellen” benamst. Er kann über die MMC “Zertifikate” eingesehen werden. Zertifikate von CAs, die hier liegen, werden vom System automatisch als vertrauenswürdig erachtet. Wie die dort hin kommen? Mit dem Windows-Betriebssystem kommen schon einige mit – und der Speicher wird per Windows-Update aktuell gehalten.

Jaja, sie hören schon richtig. Microsoft entscheidet im Windows OS standardmäßig für Sie, welche Stammzertifizierungsstellen als vertrauenswürdig angezeigt werden und welche nicht. Die Stammzertifizierungsstellen, die schon hinterlegt sind, sind allesamt kommerziell, d.h deren Zertifikate kosten einen, äh, kleinen Obulus – jährlich. Nein, ich bin kein Schelm. Sie vielleicht?

Warum dann eigene Zertifizierungsstellen?

Ganz einfach: Weil diese nicht besser oder schlechter sein müssen, als das kommerzielle Pendant. Das Hauptproblem ist, dass eigene Zertifikate und deren CA standardmäßig nicht in den vertrauenswürdigen Stammzertifizierungsstellen liegen. Und die Applikation (z.B. der Browser) zeigt beim Aufruf des Zertifikats eine dicke fette Warnung an. Das – Achtung: “Zertifizierungsstellenzertifikat” muss also manuell in den Speicher geladen werden, damit die Applikation nicht mehr meckert.

Für die eigene IT ist dieser Prozess legitim und gangbar. Für Internetapplikationen eher weniger, da man Microsoft überreden müsste, das eigene, selbsterstellte Rootzertifikat via Windows Update auf alle Windowsrechner zu übertragen. Habe ich aber noch nicht versucht.

Szenario:

Die Windows-CA gibt es in zwei verschiedenen Ausführungen: Die “eigenständige Stammzertifizierungsstelle” und die “Stammzertifizierungsstelle des Unternehmens”. Erstere ist ohne Active Directory Integration, zweitere ist in Active Directory, also der Windows Domäne integriert und bietet einige nette Automatismen und Vereinfachungen. Daneben könn(t)en weitere untergeordnete CAs erstellt werden, sei es für die Lastverteilung, als auch aus Sicherheitsgründen.

Da die Zertifizierungsstelle in diesem Szenario im Internet spielen soll, werden wir eine “eigenständige Root-CA” aufsetzen, die direkt Zertifikate an Endbenutzer ausgibt.

Screencast: Installation einer eigenständigen Stammzertifizierungsstelle

Diesmal die gute Nachricht am Schluss: Die Installation dauert nur wenige Minuten. Und dafür das ganze Theater…

[Screencast kommt]

Hier die Bilderstrecke: