© Harald07, Fotolia.com

Glücklicherweise schützen immer mehr Anwendungen ihren Datentransport mit SSL. Für jeden Dienst ein selbst signiertes Zertifikat anzulegen skaliert aber nicht – eine eigene CA muss her. Doch vor dem Unterschreiben steht eine hakelige Konfiguration .

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.

Lästige Handarbeit

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 nach einem ähnlichen Muster 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/opencaU
 --enable-scepU
 --with-default-locality=MunichU
 --with-service-mail-account=ca@example.comU
 --with-ca-organization="Example CA"U
 --with-ca-country=DEU
 --enable-package-buildU
 --with-httpd-user=apache

Für den Build-Prozess hält Open CA 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> [...]

Zugang absichern

Der Admin ändert die Parameter »default_web_username« und »default_web_password« zum Zugriff auf die Weboberfläche von RA oder CA. Das Passwortfeld erwartet das Passwort in SHA1-Kodierung. Die Parameter, die der Admin dem Configure-Skript mitgegeben hat, findet er hier wieder. In der Kategorie »web server configuration« gibt er »http« oder besser »https« für das verwendete Protokoll an und passt den Hostnamen des Webservers und seinen Port an, damit die Links der Webapplikation stimmen.

Den Parameter »CRLDistributionPoints« vervollständigt er mit einer Liste der URLs der Pub-Webserver, die Clients verwenden sollen. Diese Information schreibt die CA in eine Erweiterung ihres Zertifikats. Will ein Client einen elektronischen Ausweis prüfen, erfährt er so, wo er die für den Abgleich nötigen CRLs findet.

Wer einen LDAP-Server verwenden will, trägt dessen Einstellungen in der Kategorie »ldap server configuration« ein. Er führt dazu Hostname, Port und einen Account mit Schreibrechten im LDAP auf. Er legt fest, überhaupt LDAP-Updates durchzuführen und ob Open CA sie automatisch oder auf Veranlassung des Operators zum Server schickt. Da die Software dazu Netzwerkzugriff benötigt, aktiviert sie der Admin nur auf den RA-Servern. Die Zertifikate schickt er so zum Verzeichnisdienst, sobald er sie vollständig von der CA zurückbekommt.

Als Nächstes konfiguriert der Admin die verwendete Datenbank. Wenn er als »dbmodule« den Wert »DB« auswählt, verwendet die PKI-Software Berkeley-DB-Dateien, bei »DBI« eine relationale Datenbank, deren Parameter später zu konfigurieren sind. Bei »db_type« gibt er den Namen des Perl-DBD-Treibers ein, etwa »Pg« für PostgreSQL oder »mysql« für MySQL. Dem folgen Username, Passwort, Name der Datenbankinstanz und der Host, auf dem die Datenbank läuft. Schließlich gibt es noch den Parameter »Namespace«, der für ein Datenbankschema steht.

SCEP auf dem RA-Server hat eine eigene Kategorie und benötigt ein Zertifikat, einen Private Key sowie das zugehörige Passwort für die SCEP-Komponente im PEM-Format. Dies lässt sich zum Beispiel an einem Base-64-Block zwischen den Begrenzungen »BEGIN« und »END CERTIFICATE« erkennen.

Austausch ohne Netz

CA und RA tauschen Daten aus. Im Bereich »dataexchange configuration« legt der Admin fest, welche Austauschmöglichkeiten die Weboberfläche unter der URL [http://ra/pki/node] anbietet. Hier gibt es vorgefertigte Konfigurationsblöcke je nach Rolle des konfigurierten Servers. Für den CA-Server kommentiert der Admin den Block 1 ein, für den RA- und den Pub-Server den Block 5.

01 <VirtualHost _default_:443>
02   ServerRoot "/opt/openca/var/www"
03   ScriptAlias /cgi-bin/pki/ "/opt/openca/var/www/cgi-bin/pki/"
04   DocumentRoot "/opt/openca/var/www/html"
05   Alias /pki/ /opt/openca/var/www/html/pki/
06   ServerName ra.localnet
07   <Directory "/opt/openca/var/www/cgi-bin">
08     SSLOptions +StdEnvVars
09     Order allow,deny   Allow from all
10   </Directory>
11   SSLEngine on
12   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:+EXP:!eNULL
13   [...]
14 </VirtualHost>

Am Ende der Datei fragt die Software nach einem Pfad zu einem Gerät oder einer Datei. Dort schreibt sie die Daten hin, die RA und CA austauschen müssen. Die Vorgabe ist noch »/dev/fd0« für eine Floppy Disk, im Zeitalter von USB-Sticks bieten sich jedoch Tar-Dateien an, die der Webserver schreiben und lesen darf und auf das Medium der Wahl kopiert. Die tatsächlichen Konfigurationsdateien erzeugt schließlich das Skript »configure_etc.sh« aus der Datei »config.xml«.

Zum Webserver gehört ein Daemon auf CA und RA. Den startet der Admin mit »/opt/openca/etc/openca/openca_start«. Im Produktiveinsatz empfiehlt es sich, ein Init-Skript zu schreiben, denn das Paket liefert keins mit. Wer eine Datenbank nutzt, hier beispielhaft PostgreSQL, bereitet sie mit »psql template1« vor:

template1=# CREATE USER opencaU
  WITH ENCRYPTED PASSWORD 'openca';
CREATE USER
template1=# CREATE DATABASE opencaU
  WITH owner=openca encoding='utf-8';
CREATE DATABASE
template1=# CREATE SCHEMA opencaU
  AUTHORIZATION openca;
CREATE SCHEMA

Im letzten Schritt ist noch der Webserver anzupassen. Das Readme schlägt zwar detailgenaue Pfade vor, aber es geht kürzer: Listing 2 konfiguriert einen Virtualhost für die RA. Der Admin aktiviert für einige Pfade »SSLRequire«, damit die Anwendung sein Clientzertifikat prüft. Bei der CA ist das der »Node«-Bereich zum Datenaustauch, bei der RA alles außer dem »Pub«-Bereich für die Anwender. Die haben schließlich eingangs noch gar kein Zertifikat. Die Meldung »You are using a too short symmetric key length« gibt nicht direkt den Hinweis, dass das Clientzertifikat fehlt.

Erste Einrichtung

Den CA-Admin begrüßt der Webserver unter [http://ca/pki/ca] mit einer Login-Maske. Er meldet sich mit den Zugangsdaten aus »config.xml« an. Die Oberfläche (siehe Abbildung 3) führt ihn unter »PKI Init & Config« durch die ersten Schritte. Zunächst initialisiert er die Datenbank, dann generiert er den Private Key der CA. Daraus erzeugt die Software einen Zertifikatsrequest (CSR), den er dann selbst unterschreibt. Das Passwort des Schlüssels sollte er redundant sichern, denn wenn es verloren geht, sind alle ausgestellten Zertifikate wertlos. Wenn er die eigene CA von einer übergeordneten CA unterschreiben lassen möchte, kann er das CSR auch exportieren und das unterschriebene Zertifikat anschließend importieren.

Abbildung 3: Nach der Konfiguration belohnt Open CA Operateure mit einer Web-basierten PKI-Oberfläche.

Im nächsten Schritt stellt der CA-Operator sich selbst ein Zertifikat aus, um sich zukünftig gegenüber der Software auszuweisen. In der zugehörigen Auswahlmaske wählt er dafür zusätzlich »User«, der sonstige Ablauf unterscheidet sich nicht vom Erzeugen des CA-Zertifikats. Um sich künftig gegenüber der CA zu authentifizieren, importiert der Operator den Nachweis in seinen Browser.

Um das Einrichten der CA abzuschließen, durchläuft er das Verfahren ein drittes Mal, um ein Serverzertifikat für den RA-Webserver anzulegen. Hier wählt er als Typ ein Serverzertifikat. Andere Typen lehnen Browser ab, die sich an die RA wenden. Der Admin exportiert Zertifikat und Private Key im Format »SSLeay«, da er so Dateien im PEM-Format erhält, mit dem Webserver direkt umgehen können. Eine Ausnahme ist der Fall, wenn er die Angaben auf unsicherem Weg von der CA zur RA transportiert. Das »p12«-Format exportiert den Beleg und seinen geheimen Schlüssel in einem Container, den es mit einem Passwort schützt.

Ist die RA mit beiden Zertifikaten ausgestattet, greift der Operator per Browser auf die Weboberfläche der CA zu und geht im Hauptmenü auf »PKI Init & Config | Go To | Node Management«. Unter dem Eintrag »Node Ops« wählt er »Import/Export« und unter »Enroll Data to a lower level of the Hierarchy« die Auswahl »All«, um so alle Daten für die RA zusammenzufassen. Dies erzeugt die Datei, die der Admin am Ende der »config.xml« konfiguriert hat. Sie ist auf die RA zu kopieren und dort über den gleichen Menü-Eintrag im Node »Management« der RA wieder zu importieren. Damit ist sie einsatzbereit. Benutzer können fortan im Pub-Bereich Zertifikate beantragen, Admins werfen ein Auge auf das Logfile »/opt/openca/var/openca/log/stderr.log«, das bei einer Fehlersuche hilft.

Beantragende Benutzer

Um sich über die Policy der CA zu informieren, rufen Benutzer [https://ra/pub] auf. Die Seite erläutert die organisatorischen Bedingungen und erlaubt es, die aktuelle CRL herunterzuladen und ein Zertifikat zu beantragen. Das darf der Anwender über den Browser erzeugen oder einen bestehenden PKCS#10-Request mit Cut&Paste in ein Formular einfügen. Insbesondere Server nutzen diesen Weg. Der RA-Operator sieht anschließend in der Liste der Requests die Anfrage. Lehnt er ihn nicht ab, bestätigt er ihn und leitet ihn signiert zur CA weiter.

Die RA exportiert Daten zu einer höheren Hierarchiestufe, also transportiert der Operator die erzeugte Datei zur CA. Dort importiert er sie von einer unteren Ebene: Der CA-Operator sieht vom RA-Operator genehmigte Requests, unterschreibt sie und leitet sie zurück zur RA. Die verschickt beim Import eine E-Mail, sofern der Admin eine E-Mail-Adresse hinterlegt hat, oder überträgt sie ins LDAP.

Nach Mühe doch nützlich

Anwender finden das fertige Zertifikat im Pub-Bereich und laden es herunter. Dort können sie auch bestehende Nachweise zurückziehen: Sie selbst oder die RA- oder CA-Operateure unterzeichnen einen entsprechenden Antrag, der schließlich als Eintrag in einer CRL erscheint.

Eine CA betreiben ist ein aufwändiges Geschäft, die damit verbundenen Prozesse sind vielfältig und eng miteinander verzahnt. Nur wer sich intensiv damit auseinandergesetzt hat, vermeidet implizite Sicherheitslücken. Dabei hilft Open CA jenen, die konsequent und bei allen Diensten X.509v3-Zertifikate zur Authentisierung nutzen wollen. Es macht den Verwaltungsaufwand einer CA erträglich, wenn auch zum Preis einer aufwändigen Installation und Konfiguration. Wünschenswert wären eine etwas aktuellere Paketierung und eine Dokumentation, die auch auf die Details des täglichen Betriebs eingeht.

Wer sich aber dafür entscheidet, darf sich über eine Software freuen, die die wichtigsten Abläufe modelliert. So bringen die Details, etwa das Backup der Schlüssel direkt aus der Weboberfläche heraus, den entscheidenden Vorteil: Eine CA, die ihren Schlüssel verliert, bedeutet schließlich mehr Ärger als Nutzen. (mg)