Zertifikate mit OpenCA 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 OpenCA stellt Zertifikate aus und verwaltet sie zentral [3].

OpenCA 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 OpenCA 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.

Offline

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 OpenCA 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 OpenCA 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.

OpenCA 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.

OpenCA 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.

Leider ist das Projekt, das 1998 der Italiener Massimiliano Pala gründete, nicht sehr aktiv. Die letzte Version 1.0.2 datiert vom Oktober 2008, aber die Webseite bietet nur fertige Pakete für Fedora 6 und 9, Centos 4.7, Ubuntu 7.10 und Open Solaris an. Leider hat keine der großen Distributionen ein eigenes Paket im Angebot, sodass Interessierte sich auf aufwändige manuelle Arbeiten aus den Quellen einstellen müssen [5]. Die Installation besteht aus dem üblichen »./configure && make && make install« , jedoch läuft der Anwender schnell in einige nicht offensichtliche Fallen, nicht zuletzt weil mehrere Komponenten zu installieren sind.

Die Binärpakete installieren sich ins Verzeichnis »/opt/openca« , dieser Vorgabe folgt auch das Beispiel. Das Einrichten von RA und CA läuft ähnlich ab. Der Admin installiert zuerst die CA vollständig. Die in Betrieb genommene Certificate Authority ist notwendig, da sie Zertifikate für RA und deren Webserver ausstellt.

Bevor sich der Admin den Paketen der CA zuwendet, installiert er die »openca-tools« in der Version 1.1.0 vom Downloadbereich der Webseite [6]:

./configure --prefix=/opt/openca
make
sudo make install

Der Systemverwalter nimmt in den Pfad »/opt/openca/bin« auf und richtet das Paket »openca-base« ein. Dabei aktiviert er SCEP und legt die Attribute für das spätere CA-Zertifikat fest. Zusätzlich teilt er der Installtionsroutine die User-ID des Webservers mit, da dieser später einige Dateien lesen und schreiben möchte:

./configure --prefix=/opt/openca--enable-scep--with-default-locality=Munich--with-service-mail-account=ca@example.com--with-ca-organization="Example CA"--with-ca-country=DE--enable-package-build--with-httpd-user=apache

Für den Build-Prozess hält OpenCA eine Reihe von Make-Targets vor, die »make help« anzeigt, Tabelle  1 listet die wichtigsten auf. Die Targets bauen und installieren jeweils die Komponenten, die für die Aufgabe der RA oder CA nötig sind. Sie installieren in der Verzeichnisstruktur der Webseiten unterhalb von »pki/« nur die Programmteile, die für die Aufgabe notwendig sind. Das Target »ca« steht für die CA und »ext« für die RA. Für die Installation heißen die Targets leider nicht passend dazu »install-offline« und »install-online« .

Als Nächstes passt der Admin »config.xml« an, die als Masterdatei für alle anderen Konfigurationsdateien dient (siehe Listing  1). Sie befindet sich im Verzeichnis »/opt/openca/etc/openca/« . Alle Konfigurationsparameter sind mit den Tags »<name>« und »<value>« gekennzeichnet.

01 <?xml version="1.0" encoding="UTF-8"?>
02 <openca><software_config>
03   <prefix>@</prefix>
04   <option>
05     <name>organization</name>
06     <value>Elwood CA</value>
07   </option>
08   <option>
09     <name>CRLDistributionPoints</name>
10     <value>URI.1=http://ra/pki/pub/crl/l.crl</value>
11   </option>
12   <!-- ldap server configuration -->
13   <option>
14     <name>ldap_host</name><value>ldapserver</value>
15   </option>
16   <!-- database configuration -->
17   <option>
18     <name>dbmodule</name> <!-- DB or DBI -->
19     <value>DBI</value>
20   </option>
21  <option>
22    <name>db_type</name><value>Pg</value>
23  </option> <I>[...]<I>