Das Login auf Webseiten mittels Nutzernamen und Passwort birgt Gefahren. Für mehr Sicherheit sorgt der Apache-Webserver mit einer zertifikatsbasierten Anmeldung.

Foren, Blogs oder Content-Management-Systeme besitzen meist eigene Authentifizierungssysteme. Doch auch der Webserver selbst erlaubt die Zugangskontrolle – fast jeder Anwender sah die so genannte .htaccess-Abfrage (Abbildung 1) schon einmal. In jüngerer Zeit hält zudem das OpenID-Verfahren Einzug, bei dem eine einzige Kennung als eine Art Single-Sign-On den Zugriff auf verschiedene Seiten öffnet. All diese Möglichkeiten verbindet, dass sie lediglich zwei Daten abfragen: Benutzername und Passwort. Gelangen diese Informationen in die falschen Hände, stehen Dritten alle Türen offen.

.htaccess haftet ein Makel an: Geraten die Login-Daten in falsche Hände, stehen jedem Tür und Tor offen.” width=”300″ height=”88″ /> Abbildung 1: Der klassischen Anmeldung per .htaccess haftet ein Makel an: Geraten die Login-Daten in falsche Hände, stehen jedem Tür und Tor offen.

Als wesentlich sicherer erweist sich die Authentifizierung per Zertifikat: Sie überträgt beim Anmelden kein Passwort, sondern einen Schlüssel, der als Datei auf Ihrer Festplatte liegt. Diese Datei wiederum schützt ein Kennwort, sodass ein potentieller Angreifer nicht nur den Schlüssel, sondern auch das geheime Passwort benötigt. Dieses ändern Sie bei Bedarf jederzeit problemlos. Erscheint auch das noch zu riskant, speichern Sie das Zertifikat auf einem so genannten USB-Token oder einer Smartcard.

Viele Anwender kennen dieses Prinzip der zertifikatsbasierten Authentifizierung schon von der E-Mail-Verschlüsselung, denn sowohl PGP als auch S/MIME funktionieren mit passwortgeschützten Schlüsseln. Wer viele Server administriert, verwendet in den meisten Fällen zur Anmeldung via SSH ebenfalls die zertifikatsbasierte Anmeldung, die einen Key anstelle eines Passworts überträgt.

Schlüssel, Zertifikate, Zertifizierungsstelle – das klingt zunächst kompliziert, bietet aber handfeste Vorteile. Zum einen stellt die Notwendigkeit des Zertifikats oder der Zugriff auf die Smartcard ein weitaus größeres Hindernis für Angreifer dar als eine Passwortabfrage. Zum anderen stellen viele Unternehmen ohnehin Zertifikate für Ihre Mitarbeiter aus. Desweiteren lassen diese sich viel komfortabler zentral verwalten als simple Passwörter, da sie von Hause aus Gültigkeitsdauern und Sperrlisten unterstützten.

Allerdings bringt diese Art der Authentifizierung auch Nachteile mit sich: Mal eben vom PC des Kollegen am Server einloggen funktioniert genauso wenig wie der Zugriff auf wichtige Daten, wenn der Schlüssel durch einen Absturz verloren ging. Auch eignet sich ein solcher Schutz nur dann, wenn jeder Mitarbeiter einen entsprechenden Schlüssel erhält. Aber gerade weil diese Methode das Login nicht “mal eben” von jedem Gerät aus ermöglicht, trägt sie maßgeblich zur Sicherheit bei.

Grundverschlüsselung

Das Testsystem besteht sowohl auf dem Client als auch dem Server aus Ubuntu 10.10. Als Webserver kommt Apache aus den Ubuntu-Paketquellen zum Einsatz, als Browser Firefox 4.0 direkt von Mozilla [1]. Apache installieren Sie mittels

# apt-get install apache2-suexec apache2-mpm-prefork

Nach der Installation aktivieren Sie das SSL-Modul mit dem Kommandozeilenbefehl sudo a2enmod ssl. Zum Aktivieren von SNI (siehe Kasten “Was ist SNI?”) fügen Sie in die Datei /etc/apache2/ports.conf den Eintrag NameVirtualHost *:443 unter der bereits vorhandenen Zeile ein, und starten Apache abschließend mit der Eingabe von sudo /etc/init.d/apache2 reload neu.

Der Webserver muss bereits in der Lage sein, verschlüsselte Seiten auszuliefern, bevor er auch Zertifikate zur Anmeldung akzeptiert. Richten Sie deswegen zunächst eine gewöhnliche SSL-verschlüsselte Seite ein und stellen Sie sicher, dass diese funktioniert. Erst danach fügen Sie die Authentifizierung hinzu. Fehlt die virtuelle Seite, holen Sie das mit den folgenden Schritten nach:

• Legen Sie im Ordner /etc/apache2/sites-available/vhost.dmn.tld eine Datei mit dem Inhalt von Listing 1 ab. Diese beschreibt den virtuellen Host und kommt auch später zur Konfiguration der Authentifizierung zum Einsatz. Statt vhost.dmn.tld benutzen Sie den Namen der Seite. Setzen Sie ein so genanntes Chained SSL Certificate ein, ergänzen Sie das noch um die Zeile SSLCertificateChainFile /etc/ssl/certs/vhost.dmn.tld.chain
• Erstellen Sie mittels mkdir -p /var/www/sites/vhost.dmn.tld ein Verzeichns, in dem Sie den Inhalt der Webseite ablegen.
• Aktivieren Sie die neue Seite durch a2ensite vhost.dmn.tld und starten anschließend Apache neu.
• Setzen Sie eine Firewall ein und öffnen Sie abschließend den TCP-Port 443, beispielsweise über sudo ufw allow 443/tcp.

<VirtualHost *:443>
ServerName vhost.dmn.tld
DocumentRoot /var/www/sites/vhost.dmn.tld
SSLEngine On
SSLCertificateFile /etc/ssl/certs/vhost.dmn.tld.crt
SSLCertificateKeyFile /etc/ssl/private/vhost.dmn.tld.key
</VirtualHost>

Das SSL-Zertifikat zum Betrieb der Seite sowie den dazugehörigen Key erzeugen Sie mit den selben Tools, die Sie auch zur Zertifikatsverwaltung einsetzen, etwa XCA [2] oder TinyCA [3]. Für einen ersten Test genügt auch ein manuell gefertigtes Zertifikat. Wie Sie es erstellen, zeigt Listing 2. Alternativ – aber aufgrund der Kosten nur für große Firmen praktikabel – nutzen Sie ein eigenes Intermediate Certificate Ihres Anbieters.

$ openssl req -new > vhost.dmn.tld.csr -newkey rsa:2048 -keyout vhost.dmn.tld.pem
$ openssl rsa -in vhost.dmn.tld.pem -out /etc/ssl/private/vhost.dmn.tld.key
$ openssl x509 -in vhost.dmn.tld.csr -out /etc/ssl/certs/vhost.dmn.tld.crt -req -signkey /etc/ssl/private/vhost.dmn.tld.key -days 3650

Rufen Sie nun die Webseite im Browser auf, erhalten Sie – sofern das Zertifikat nicht von einer bekannten CA (Certificate Authority) stammt – eine Fehlermeldung (Abbildung 2). Nach dem Bestätigen der Warnung zeigt die Adresszeile des Browsers durch ein blau hinterlegtes Symbol (Abbildung 3) die aktive Verschlüsselung an.

Abbildung 2: Die Firefox-Meldung warnt vor Ihrem noch unbekannten Zertifikat.

Abbildung 3: Der blaue Balken neben der Adresszeile weist auf die verschlüsselte Verbindung hin.

Nur mit Eintrittskarte

Danach gilt es, dem Webserver mitzuteilen, dass er nicht nur Verbindungen verschlüsseln soll, sondern auch Clients per SSL-Zertifikat authentifiziert. Die gültigen Schlüssel legen Sie dabei nicht etwa individuell fest, sondern speichern alle erlaubten Zertifizierungsstellen in einer Datei. Ist das vom Client angebotene Zertifikat von einer der dort genannten CAs signiert, gewährt Apache den Zugriff.

Verfügen Sie schon über eine Zertifizierungsstelle und wurden die Browser der Anwender richtig konfiguriert, dann genügt es, wenn Sie den virtuellen Host in /etc/apache2/sites-available/vhost.dmn.tld noch um die Zeilen aus Listing 3 ergänzen und Apache neu starten.

SSLCACertificateFile /etc/ssl/certs/intranet-ca.crt
SSLVerifyClient require
SSLVerifyDepth 5

Zeile 1 besagt, dass sich alle Zertifikate, die von den in /etc/ssl/certs/intranet-ca.crt genannten Zertifizierungsstellen unterschrieben sind, anmelden dürfen. Die Direktive in Zeile 2 erzwingt durch (require) die Anmeldung per Zertifikat. Beachten Sie: Ohne diese Anweisung findet keine Authentifizierung statt. Zeile 3 erlaubt fünf Zwischenzertifikate, was insbesondere für große Zertifizierungsstellen wichtig ist. Stammen alle Zertifikate direkt von der CA ohne Zwischen-Instanzen ab, tragen Sie hier 1 ein.

Je nach Browser erfolgt die Authentifizierung automatisch nach der Eingabe des Master-Passworts oder der Auswahl des entsprechenden Zertifikats. Im Fall von Firefox stellen Sie sicher, dass unter Bearbeiten | Einstellungen | Erweitert | Verschlüsselung, die Option Jedes Mal fragen aktiv ist (Abbildung 4). Das hilft zumindest während der Installation am Server dabei, Fehler zu entdecken. Nach dem Konfigurieren des Servers und dem Ausstatten des Browsers mit dem Zertifikat fragt der Browser sie beim nächsten Besuch der Seite danach (Abbildung 5).

Abbildung 4: Vor allem beim Einrichten des Servers hilft es, dass Firefox jedes Mal nach dem zu benutzenden Zertifikat nachfragt.

Abbildung 5: Vollendet: Nach dem Einrichten erscheint anstelle der Passwortabfrage die nach dem passenden Zertifikat.

Diese Technik erlaubt beim Passwortschutz per .htaccess das Absichern einzelner Verzeichnisse oder Adressen. Um beispielsweise nur das Wiki zu schützen, konfigurieren Sie den virtuellen Host wie in Listing 4 gezeigt. Dort sehen Sie gleichzeitig auch, wie Sie mittels mod_rewrite [4] automatisch alle unverschlüsselten Aufrufe umleiten. Achtung: Hier gibt es ein Sicherheitsrisiko, das der Kasten “Sicherheitsrisiko bei mehreren virtuellen Hosts” beschreibt. Mod_rewrite müssen Sie nur vorher per a2enmod rewrite aktivieren. Die Nutzung von Mod_rewrite ist übrigens keineswegs zwingend, sondern erspart Anwendern lediglich das händische Eintippen des HTTPS-Protokolls.

<VirtualHost *:80>
ServerName vhost.dmn.tld
DocumentRoot /var/www/sites/vhost.dmn.tld-80
RewriteEngine on
RewriteRule ^(.*) https://%{SERVER_NAME}$1 [NE,L]
</VirtualHost>
<VirtualHost *:443>
ServerName vhost.dmn.tld
DocumentRoot /var/www/sites/vhost.dmn.tld
SSLEngine On
SSLCertificateFile /etc/ssl/certs/vhost.dmn.tld.crt
SSLCertificateKeyFile /etc/ssl/private/vhost.dmn.tld.key
<Location /wiki>
SSLCACertificateFile /etc/ssl/certs/intranet-ca.crt
SSLVerifyClient require
SSLVerifyDepth 5
</Location>
</VirtualHost>

Der Notar im eigenen Haus

Am Beispiel der freien Software XCA zeigen wir Ihnen den Aufbau einer kleinen Zertifizierungsstelle zu Testzwecken. Sie erhalten das Programm als fertiges Ubuntu-Paket mittels apt-get install xca und starten es im GNOME-Menü unter Anwendungen | Zubehör | XCA. Der Aufbau einer kleinen Testinstanz läuft dabei in drei Schritten ab: Erzeugen der XCA-eigenen Datenbank, Erstellen der Zertifizierungsstelle und zuletzt Ausstellen von Zertifikaten mit der neuen CA.

Nach dem Start von XCA klicken Sie auf Datei | New DataBase und wählen den Speicherort für die Datenbank. Darin legt das Programm sämtliche Schlüssel und Zertifikate ab – verwahren Sie diese daher gut, und wählen Sie ein sicheres Passwort.

Erstellen Sie unter dem ersten Reiter mindestens zwei private Schlüssel – einen für die Zertifizierungsstelle selbst und einen für den ersten Client beziehungsweise Benutzer. Als Schlüsseltyp wählen Sie RSA mit einer Länge von 2048 Bit. Vergeben Sie möglichst eindeutige Namen, wenn sie auch nur intern zum Einsatz kommen. Planen Sie mehrere Benutzer, legen Sie für jeden einen eigenen Schlüssel an. Hier zeigt sich auch, warum es sich derzeit nur um eine Testinstanz handelt – im Normalfall erstellt sich jeder Anwender aus Sicherheitsgründen den Schlüssel selbst.

Auf der nächsten Registerkarte erstellen Sie zu jedem Schlüssel eine Unterschriftsanfrage. Beachten Sie, unter Vorlage den richtigen Typ auswählen, den Sie anschließend übernehmen: CA für die Zertifizierungsstelle, also genau einmal, und für jeden Benutzer HTTPS_client. Als Algorithmus empfiehlt sich generell SHA-512. Unter Besitzer wählen Sie den korrespondierenden Schlüssel aus, und füllen unter Distinguished Name die Angaben zum Zertifikatsinhaber aus (Abbildung 6).

Abbildung 6: Umständliche Kommandozeilenbefehle gehören dank XCA der Vergangenheit an. Mit der Software erstellen Sie im Handumdrehen die notwendigen Zertifikate.

Im nächsten Schritt erstellen Sie das Zertifikat in der entsprechenden Registerkarte. Auch hier übernehmen Sie wieder die korrekte Vorlage und setzen den Algorithmus. Anschließend wählen Sie die zu signierende Anfrage. Hier gibt es einen kleinen, aber wichtigen Unterschied: Beim Erstellen der CA müssen Sie ein selbst signiertes Zertifikat erzeugen, die Benutzer hingegen mit der soeben erzeugten CA unterschreiben (Abbildung 7). In jedem Fall deaktivieren Sie Copy extensions from the request, da es sonst zu Fehlermeldungen kommt. Danach zeigt XCA die Benutzer-Zertifikate unterhalb der Zertifizierungsinstanz an (Abbildung 8).

Abbildung 7: Die Test-CA unterschreibt das Zertifikat vom Admin.

Abbildung 8: Hierarchische Darstellung: Die Test-CA signiert drei Benutzerzertifikate.

Das Runde ins Eckige

Nun gilt es, das Zertifikat samt Schlüssel auf die Browser der Anwender zu verteilen und auch dem Webserver die CA bekannt zu machen. XCA hält dafür eine praktische Exportfunktion bereit. In unserem Beispiel speichern Sie das Zertifikat der CA im so genannten PEM-Format unter /etc/ssl/certs/intranet-ca.crt ab. Die Zertifikate der Benutzer speichern Sie dagegen als PKCS #12, denn sie enthalten auch den privaten Schlüssel.

Um Firefox das Zertifikat bekannt zu machen, gehen Sie auf Bearbeiten | Einstellungen | Erweitert | Verschlüsselung | Zertifikate anzeigen | Ihre Zertifikate und klicken auf Importieren…. Nach Eingabe des korrekten Kennworts, mit dem Sie die Datei beim Export aus XCA verschlüsselt haben, stehen die Zertifikate zur Verfügung (Abbildung 9). Einige Browser – im Test unter anderem Opera – verlangten zudem die Installation des öffentlichen CA-Zertifikats (PEM-Datei).

Abbildung 9: In der Zertifikatsverwaltung von Firefox erscheint jetzt auch Ihres.

Fazit und Ausblick

Die Konfiguration der Authentifizierung per Zertifikat gestaltet sich zwar aufwändig, bringt aber einen erheblichen Sicherheitsvorteil gegenüber den passwortbasierten Anmeldeverfahren. Allerdings gilt es, den Aufbau einer eigenen Zertifizierungsinstanz vorab gut zu planen. Im Produktivbetrieb sollten Sie zusätzlich eine Sperrliste (CRL) implementieren. Weiterhin sollten Sie zum Schutz vor Kompromittierung auch über den Einsatz von Zwischen-CAs nachdenken. Einen guten Überblick über die Serverseite liefern die Apache-eigene Dokumentation ([5],[6]), den Rest erklärt das Handbuch der eingesetzten PKI-Lösung.