Wenn die Ansprüche an die Infrastruktur für die Authentifizierung von Benutzern, Rechnern oder Diensten größer werden, stößt das übliche Benutzername/Passwort- Schema schnell an seine Grenzen. Die Standardlösung für dieses Problem heißt: Zertifikate. Dieser Artikel beschreibt den Aufbau einer eigenen Zertifizierungsstelle und stellt das Werkzeug TinyCA vor, das zumindest bescheidenen Ansprüchen genügt.

Wenn die Ansprüche an die Infrastruktur für die Authentifizierung von Benutzern, Rechnern oder Diensten größer werden, stößt das übliche Benutzername/Password-Schema schnell an seine Grenzen. Die Standardlösung für dieses Problem heißt: Zertifikate. Dieser Artikel beschreibt den Aufbau einer eigenen Zertifizierungsstelle und stellt das Werkzeug TinyCA vor, das zumindest bescheidenen Ansprüchen genügt.

Wozu eine Zertifizierungsstelle?

Das übliche Schema zur Authentifizierung durch Benutzername und Passwort skaliert nicht besonders gut. Sobald es etwas mehr Benutzer werden, hat der Administrator alle Hände voll zu tun, die Passwortdateien für alle Hosts und Dienste anzupassen. Die Alternative dazu ist, dass jeder Benutzer sich mit einem so genannten Zertifikat ausweist und jeder Rechner beziehungsweise Dienst diesem Ausweis vertraut.

Benutzer können sich mit dem Zertifikat gegenüber einem Server ausweisen und dieser muss nur noch prüfen, ob das Zertifikat ordnungsgemäß von einer CA, der er vertraut, unterschrieben wurde. Dann erhält der Benutzer Zugang zu den angebotenen Diensten. Vorteil für den Administrator ist, dass der Server nur noch das Zertifikat der CA kennen muss. Es müssen keine tausende von Benutzerkonten angelegt werden.

Für einen solchen Ausweis benötigt der Benutzer (oder auch ein Rechner, der sich ausweisen will) ein Paar aus öffentlichem und privatem Schlüssel. Da nur der Benutzer den privaten Teil kennt, ist sichergestellt, dass nur er Zugang zum Server bekommt, die verschlüsselten Daten lesen kann und so fort.

Aus dem öffentlichen Schlüssel wird ein Zertifikat, wenn eine zentrale Vertrauensinstanz ihn durch ihre Signatur bestätigt hat. Damit bestätigt sie, dass der Besitzer des Zertifikats tatsächlich der ist, für den er sich ausgibt. Deshalb ist es für die Zentralinstanz wichtig, die Authentizität des Benutzers vor der Ausgabe des Zertifikats zu überprüfen.

Da jedes Zertifikat, das von der CA signiert wurde, bis zu seinem Ablaufdatum gültig ist, muss es auch einen Mechanismus geben, Zertifikate zwischendurch zu widerrufen. Das kann der Fall sein, wenn das Zertifikat zum Beispiel verloren ging. In diesem Fall markiert die CA das Zertifikat als ungültig und exportiert diese Liste in die so genannte Certificate Revocation List (CRL). Dem Administrator bleibt es vorbehalten, diese CRL auf alle Server zu verteilen, um so unerlaubten Zugang zu verhindern.

TinyCA & Co

Der Standard für die Erstellung von Zertifikaten in der offenen Welt ist OpenSSL; ein Kommandozeilenwerkzeug, das zwar alles notwendige kann, aber für Crypto-Neulinge nicht unbedingt leicht zu bedienen ist. Alternativ bringen Distributionen und Programme eigene Scriptsammlungen mit, die dem Administrator dabei helfen, Zertifikate zu erstellen. Diese Werkzeuge dienen immer genau einem Zweck, erstellen zum Beispiel ein Zertifikat für einen Webserver. Universell sind sie meist nicht einsetzbar. Gute CAs bringen meist nur die Enterpriseversionen von Red Hat oder Suse Linux mit.

Für den Hausgebrauch bei nicht allzu großen Anforderungen hat sich daneben im Einsatz auch das Programm TinyCA bewährt. Es bietet eine Gtk-GUI, die es einem Administrator erlaubt, eine (oder mehrere) CAs lokal auf seinem Rechner zu verwalten, Anforderungen selbst zu erstellen oder zu importieren und für beliebige Zwecke zu signieren, also Zertifikate zu erstellen.

Ein installationsfertiges RPM in der Version 0.7.5 gibt es auf der Projektseite. Debian-Pakete sind im Unstable-Zweig zu finden. Die Installation funktioniert einfach mit Bordmitteln (RPM oder Apt-Get). Nach erfolgreicher Installation liegt das Programm »tinyca2« unter »/usr/bin« und kann direkt aufgerufen werden.

Arbeiten mit TinyCA

Beim ersten Öffnen will TinyCA eine neue CA erstellen, falls es noch keine im Verzeichnis ».TinyCA« findet. Wie in Abbildung 1 dargestellt, können jetzt die Daten der eigenen Firma eingegeben werden.

Abbildung 1: Am Anfang aller Zertifikatsaufgaben steht der Aufbau einer eigenen Certificate Authority (CA). Hier das dazu gehörige Fenster in TinyCA.

Wichtig ist, dass die Gültigkeit der CA (hier 3650 Tage oder 10 Jahre) nicht zu kurz eingegeben wird. Falls die CA ungültig wird, verlieren auch alle Zertifikate ihre Gültigkeit. Ein Erneuern der CA ist, im Gegensatz zu einzelnen Zertifikaten, nicht möglich!

Sobald die CA erzeugt ist, füllt TinyCA das Verzeichnis ».TinyCA/ Name-der-CA« mit Daten. Die Konfigurationsdatei »openssl.cnf« enthält alle wichtigen Vorgaben für den Aufruf des Programms »openssl«. Die Datei »cacert.key« enthält den privaten(!) Schlüssel der CA, der mit dem eingegebenen Passwort verschlüsselt wurde. Diese Datei muss besonders geschützt werden und darf nicht in falsche Hände geraten. Der Administrator muss sich auch das Passwort der CA unbedingt merken, da nur damit die CA funktioniert. Schließlich enthält die Datei »cacert.pem« noch das Zertifikat der CA selbst.

Anforderungen

Mit der eben erstellten CA kann der Administrator nun die ersten Arbeiten für ein neues Zertifikat durchführen. Dazu erstellt er eine neue Anforderung, das heißt einen Schlüssel in einem bestimmten Format. Ein Rechtsklick im Feld »Anforderungen | Neue Anforderung« öffnet den Dialog für eine neue Anforderung. Wichtig sind der »Common Name (CN)« und die Mailadresse, die als Attribute im Zertifikat wieder auftauchen. Über den Common Name wird der Benutzer des Zertifikats identifiziert.

Das Passwort schützt den privaten Schlüssel. Es wird benötigt, um das Zertifikat später für die Authentifizierung nutzen zu können. Passwörter für Schlüssel, die später in Server-Zertifikaten eingesetzt werden, sind problematisch, da Dienste normalerweise automatisch starten und keine Passwortabfrage bieten. Nur wenn es die Konfiguration eines Dienstes zulässt, ein Passwort zum Öffnen des Schlüssels zu hinterlegen, sollte an dieser Stelle ein Passwort eingegeben werden (siehe Abbildung 2).

Abbildung 2: Die Eingabemaske, um ein neues Zertifikat anzufordern.

Die übrigen Felder sind schon ausgefüllt und passen zu den Daten der CA. Sie sollten nicht verändert werden, da diese Daten bei der Authentifizierung mit den Daten der CA verglichen werden. Bei Abweichungen kann es passieren, dass der Benutzer abgewiesen wird. Sobald die Anforderung abgeschlossen ist, erstellt TinyCA den Schlüssel und die Anforderung dazu. Sie tauchen in den entsprechenden Feldern der GUI auf.

Falls der Benutzer den Schlüssel selbst erzeugen will, muss er dem Administrator nur die Anforderung im PKCS#10-Format, schicken, die dieser dann per »Import« einlesen kann. Diese Variante hat den Vorteil, dass nur der Benutzer das Passwort für den Schlüssel kennt.

Signatur

Um aus der Anforderung nun ein Zertifikat zu erzeugen klickt der Administrator mit der rechten Maustaste auf den entsprechenden Request und wählt dann »Anforderung Signieren«. Jetzt darf er entscheiden, ob ein Zertifikat für einen Server oder einen Benutzer erstellt wird. Abhängig von dieser Entscheidung tauchen im Zertifikat später die entsprechenden Attribute auf. TinyCA fragt nun nach dem Passwort für die CA und der Gültigkeit des neuen Zertifikats (siehe Abbildung 3).

Abbildung 3: TinyCA fragt das Passwort für die CA und die Gültigkeit des neuen Zertifikats ab.

Die Gültigkeit sollte wiederum nicht zu knapp bemessen sein Allerdings kann man ein abgelaufenes Zertifikat wieder erneuern. Es bleibt der Aufwand, das neue Zertifikat dem Benutzer zuzusenden und auf dessen Rechner anstelle des Alten zu installieren. Nachdem das neue Zertifikat erstellt ist, taucht es auch im entsprechenden Abschnitt von TinyCA auf. Ein Rechtsklick auf das Zertifikat und die Auswahl »Zertifikat Detail« enthüllt alle Details zu dem Zertifikat. Hier kann man auch die Gültigkeit noch einmal nachprüfen (siehe Abbildung 4)

Abbildung 4: Auf Wunsch zeigt TinyCA alle wichtigen Details eines Zertifikats an.

Export

Zum Abschluss können Schlüssel und Zertifikat auch noch exportiert werden, damit ein Benutzer damit arbeiten kann. Dazu klickt der Administrator mit der rechten Maustaste auf das Zertifikat und wählt »Zertifikat exportieren« aus. Für den Export der Daten stehen die Formate PEM, DER und PKCS#12 zur Auswahl. Beim gebräuchlichsten Format PEM kann der Admin auswählen, ob der Schlüssel im Zertifikat enthalten sein soll. Schlüssel und Zertifikat (im Format PEM oder PKCS#12 für Windows) zusammen zu exportieren, ist sicher sehr praktisch. Allerdings muss man darauf achten, ob die Applikation, für die das Zertifikat erstellt wurde, damit umgehen kann.

Genau so einfach ist es auch, den Schlüssel in einem der Standardformate DER oder PKCS#12 zu exportieren. Im Dialog für den Schlüsselexport besteht die Möglichkeit, den Schlüssel ohne Passwort, also unverschlüsselt zu exportieren. TinyCA fragt bei Auswahl dieser Option nach, ob der Administrator wirklich weiß, was er gerade macht. Um die Integrität des Schlüssels zu gewährleisten, sollte dieser eigentlich immer verschlüsselt sein. Unverschlüsselte Dateien sind nur für Zertifikate beziehungsweise Schlüssel von Serverdiensten denkbar, die eine Schlüsseldatei nicht entschlüsseln können.

Anwendungen

Mit dem Programm TinyCA kann der Administrator schnell eine CA für die eigene Firma erstellen und Zertifikate für Web- und Mailserver erzeugen. Auch Zertifikate für eine überschaubare Anzahl von Mitarbeitern oder Rechnern zu erstellen, ist mit TinyCA kein Problem. Das vereinfacht zum Beispiel die Verwaltung des VPN-Zugangs zur Firma per OpenVPN. Auch die Authentifizierung zum eigenen Postfach über Zertifikate anstelle von üblichem Username/Passwort ist denkbar. Grundsätzlich kann man Zertifikate überall dort einsetzen, wo authentifizierter Zugang zu Diensten benötigt wird. Die GUI läßt im Notfall auch den Widerruf von Zertifikaten und den Export einer Widerrufsliste (CRL) zu. Dem Administrator bleibt es überlassen, die aktuelle CRL auf dem Server zu installieren, der die Benutzer kontrollieren soll.

Fazit

Das Schöne an TinyCA ist, dass man den Umgang mit Zertifikaten einfach lernt. Angehende Sicherheitsexperten können den Prozess der Verwaltung von Zertifikaten auf diese Weise einüben und in kleinen Umgebungen einsetzen. Für die Absicherung der CA, also für die Sicherheit der Daten, die TinyCA erzeugt, ist jeder selbst verantwortlich. Am wichtigsten ist die Sicherheit des CA-Schlüssels selbst. Unter Sicherheit ist hier sowohl Security, also die Absicherung vor unbefugtem Zugriff, als auch die Safety, also die Absicherung gegen Datenverlust, zu verstehen. Verschlüsselte Partitionen auf zwei USB Sticks, die an unterschiedlichen Orten aufbewahrt werden, sind hier sicher nicht des Guten zu viel. (ofr)