Zertifikate mit Open CA verwalten

Viele Anwendungen nutzen X.509v3-Zertifikate, um die Kommunikation mit Servern zu verschlüsseln. Oft generieren sie in ihrer Installationsroutine ein selbst signiertes Zertifikat, damit die SSL-Verschlüsselung funktioniert. Ein Anwender, der auf so geschützte Server zugreift, hat die Verbindung dorthin gegen Abhören gesichert. Aber er weiß nicht, ob der Server wirklich jener ist, der er vorgibt zu sein, wenn er die Gültigkeit des Zertifikats nicht überprüfen kann [1].

Bei Webservern kümmern sich Dienstleister kostenpflichtig oder Projekte wie Cacert [2] kostenlos um Unterschriften unter Serverzertifikate und das Vorhalten eines CA-Zertifikats. Aber auch innerhalb eines Unternehmens oder einer Organisation kommt zunehmend SSL zum Einsatz. Das Open-SSL-Paket liefert zwar mehrere Skripte und Werkzeuge mit, um die für den Betrieb einer PKI notwendigen Dateien zu erzeugen, aber ab einer gewissen Anzahl werden die Kommandozeilentools unhandlich. Um Abhilfe zu schaffen, muss eine Certificate Authority (CA) her. Das Projekt Open CA stellt Zertifikate aus und verwaltet sie zentral [3].

Verteilte Verantwortung

Open CA implementiert eine CA mit Außenstellen und Datenbankanschluss. Sowohl Benutzer wie Verwalter greifen über eine Weboberfläche auf die Software zu. Sie gliedert sich in die Certificate Authority selbst, eine Registration Authority (RA) und einen öffentlichen Bereich für die Endanwender. Einen Verzeichnisdienst, der das Online Certificate Status Protocol (OCSP) spricht, hat Open CA in ein gesondertes Projekt ausgelagert. Abbildung 1 verdeutlicht das Zusammenspiel der Komponenten.

Abbildung 1: Um ein Zertifikat zu erhalten, stellt sich ein Anwender bei einer Registration Authority über den Pub-Bereich vor. Kann er sich ausweisen, genehmigt die RA den Antrag und leitet ihn zur Siegelstelle weiter, der CA. Die stellt die Urkunde aus, schickt sie auf gleichem Wege zurück und legt sie im Verzeichnisdienst ab.

Wer eine PKI einrichten will, benötigt mindestens zwei Rechner: Da die CA mit ihrem Private Key Zertifikate unterschreibt, sollte der Betreiber sie dauerhaft vom Netz abschotten, damit niemand ihren Schlüssel kompromittiert.

Auf einem zweiten System richtet der Systemverwalter eine RA ein, um auch dezentral Zertifikatsanträge überprüfen zu können. Betreibt eine Organisation viele Standorte, kann es nützlich sein, an jedem eine RA einzurichten. Dort prüft ein autorisierter Administrator die Authentizität der Anträge und sendet sie signiert zur tatsächlichen CA. In kleineren Installationen kann der RA-Administrator die Anfrage auch ohne Signatur weiterleiten, besonders dann, wenn er in Personalunion auch der CA-Administrator ist. Die Web-basierte Schnittstelle zwischen Antragstellern und RA nennt Open CA Pub (siehe Abbildung 2). Sie läuft meist auf demselben Rechner wie die RA.

Abbildung 2: Über eine Weboberfläche – Pub genannt – stellen Anwender Anträge für neue Zertifikate.

Externe Anbindung

Neben der für Anwender gedachten Pub darf der Admin zusätzlich das Simple Certificate Enrollment Protocol (SCEP, [4]) von Cisco aktivieren. Es versorgt Router, die VPNs mit Zertifikaten authentisieren. Es ist nicht nur Aufgabe einer PKI, Zertifikate auszustellen, sondern sie auch zentral vorzuhalten. Dazu kann sich Open CA mit einem LDAP-Server verbinden und dort die elektronischen Urkunden ablegen. Als Alternative zum externen OCSPD-Projekt führt die Software auch Certificate Revocation Lists (CRLs, Sperrlisten), die sich Anwender für ihre Browser oder sonstigen Clients regelmäßig herunterladen können.

Open CA basiert auf Open SSL, einigen in C geschriebenen Programmen und einer großen Menge an Perl-Skripten und -Modulen. Dabei enthält die Distribution einige CPAN-Module, die die Suite der Einfachheit halber mitinstalliert. Die Installationsroutine legt für die Perl-Module einen eigenen Verzeichnisbaum an, sodass sie eine verwendete Perl-Installation nicht beeinträchtigt. Admins stehen hier vor einer Zwickmühle: Der pragmatische Ansatz bewahrt sie zwar vor API-Änderungen in der Distribution, sie riskieren aber auch, Sicherheitsupdates erst verspätet mitzubekommen.

Open Ca speichert seine Daten entweder in DBM-Dateien oder in einer relationalen Datenbank, für die ein Perl-DBD-Treibermodul installiert sein muss. Die Software unterstützt PostgreSQL, Oracle, DB2 und MySQL.