Einsatz und Konfiguration von Apache-SSL

Das Interesse an der Nutzung von Secure Sockets Layer (SSL) über das HTTPS-Protokoll nimmt immer mehr zu. Eine Analyse der von der international tätigen Zertifizierungsstelle Thawte Consulting für deutsche Web-Server ausgestellten Zertifikate zeigt, daß neben den traditionellen Anwendungsgebieten Online-Shopping und -Banking in letzter Zeit verstärkt Lösungen mit geschlossenen Benutzergruppen und Intranet-Anwendungen auf SSL setzen. Dabei dürfte der tatsächliche Umfang SSL-basierter Intranet-Lösungen weitaus höher liegen, da gerade auf diesen Bereich Produkte wie Entrust WebCA (www.entrust.com/webca/) oder Xcert Sentry zielen. Das Interesse an Apache-SSL belegen auch die zahlreichen Anfragen an die Redaktion, den Autor sowie in diversen Mailing-Listen und News-Gruppen. Daher sollen die bisher veröffentlichten Artikel über das Gespann Apache und SSLeay sowie deren Verbindungsglied Apache-SSL [[#lit1 1], [#lit2 2]] um weitere Grundlagen ergänzt werden.

Hinter Apache-SSL verbirgt sich zunächst der Apache-Server selbst. Dazu kommt eine Bibliothek, die die SSL-Funktionen bereitstellt: SSleay von Eric Young, die Grundlage für wohl alle freien Implementierungen des SSL-Protokolls. Und zu guter Letzt fehlt noch der Leim, der beides miteinander verbindet: Apache-SSL von Ben Laurie. Dessen Patchkit enthält ein Modul nebst Header-File sowie einige Veränderungen für die Dateien httpd.c und Configuration. All dies sollte vor Beginn des Übersetzens bereitliegen (siehe Kasten Quellen).

SSL ist kein Bestandteil der Standard-Distribution der Apache-Group. Exportbeschränkungen der US-Regierung für starke kryptographische Verfahren verhindern dies. Sie würden die ungehinderte Verbreitung des Apache über die Web-Site der Apache-Group nicht erlauben, da sich diese in den USA befindet. Andererseits erhält der Nutzer so einen Web-Server, der mit wirklich starker 128-Bit-Verschlüsselung arbeitet und auch auf diesem Gebiet die größten Konkurrenten von Netscape und Microsoft aussticht.

Selbst wenn das Einbinden von SSL ein bißchen aufwendiger ist, als nur vor der Übersetzung das entsprechende Modul in der Konfiguration zu aktivieren, erweist es sich trotzdem als unproblematisch. Prinzipiell können fast alle, auch die Nicht-Standard-Module, gemeinsam mit SSL verwendet werden. Zu den Ausnahmen gehören FastCGI und die Frontpage Extensions. Das sind aber bekannte Probleme, die in der Patch-Version 1.17 behoben sein sollten. Das dürfte Anwender mit einer ellenlangen Modulliste beruhigen. Probleme treten mit Entwicklerversionen aus der 1.3b-Reihe auf. Der Patch ist nicht dafür gemacht und nur mit einiger Nacharbeit zum Laufen zu bringen. Aber wer setzt schon Beta-Versionen für den regulären Betrieb ein ...

Offizielle Grundlage für einen lauffähigen Apache-SSL-Web-Server sind zum Zeitpunkt der Drucklegung folgende Softwarepakete:

ssleay-0.9.0 
apache-1.2.6 
apache_1.2.6+ssl_1.16

Zunächst ist SSLeay zu übersetzen, wie in [#lit1 [1]] bereits ausführlich dargestellt. Deshalb hier nur kurz für die README-Lesefaulen: der Configure-Aufruf paßt SSLeay an die verwendete Plattform an, make übersetzt. make test bietet die Möglichkeit, die korrekte Funktion des Compilats zu überprüfen, ist aber unnötig, da die Übersetzung auf einer der unterstützten Plattformen (und dazu zählt beinahe jedes System) 'eigentlich' gar nicht schiefgehen kann. Eine Installation von SSLeay ist nicht notwendig, die erzeugten Programme und Bibliotheken können im Quellenverzeichnis verbleiben.

Auspacken, übersetzen, patchen

Danach sind Apache und Apache-SSL zu entpacken. Achtung: letztgenanntes Paket tut dies im aktuellen Verzeichnis! Daher sollte man vor dem Aufruf des tar-Befehls in das Directory apache_1.2.6 wechseln (vorzuziehende Variante) oder zuvor ein eigenes Verzeichnis anlegen. Nun folgt die vielleicht schwierigste Aufgabe: Der Patch ist mittels der Befehlsfolge

patch < SSLpatch

anzuwenden. Wenn die gefürchtete Frage 'File to patch' erscheint, bestehen zwei Möglichkeiten. Entweder handelt es sich beim verwendeten patch um eine neuere Version als 2.1 (patch -v); dann besteht noch Hoffnung. Folgende Befehlszeile führt in diesem Falle zum Erfolg:

patch -d . -p 0 < SSLpatch

Anderenfalls läßt es sich nicht vermeiden, eine entsprechende patch-Version aus dem nächstgelegenen GNU-Archiv zu installieren. Danach kann die übliche Prozedur des Konfigurierens und Übersetzens beginnen. Von den SSL-spezifischen Definitionen in Configuration muß der Administrator, sofern die ursprünglichen SSLeay-Quellen noch vorhanden sind, nur SSL_BASE anpassen. Ansonsten wird diese Variable auf das Installationsverzeichnis (typischerweise /usr/local/ssl) gesetzt, und SSL_LIB_DIR erhält den Wert $(SSL_BASE)/lib. Außerdem ist im Template für das Makefile beim Target certificate das Verzeichnis apps durch bin zu ersetzen.

Weiterhin ist unbedingt in apache_ssl.c die Variable CACHE_SESSIONS mit FALSE zu definieren. Eine entsprechende Compilerdirektive ist in Zeile 83 schon fast vorgesehen. Damit wird das SSL-Session-ID-Caching abgeschaltet. Dadurch bleibt zwar die Performance bei SSL-Verbindungen weiterhin recht unbefriedigend, aber die Stabilität ist wichtiger. Falls zusätzliche (Basic-)Authentication-Module eingebunden und gemeinsam mit SSL-Client-Authentication verwendet werden sollen, ist darauf zu achten, daß sie vor dem Modul apache_ssl.o in der Configuration-Datei auftauchen. Nach Aufruf von ./Configure und make sollte das neue Binary httpsd (man beachte das s!) vorliegen.

Zunächst kann man den neuen Server mit den Konfigurationsdateien des bisher laufenden Apache-Servers starten und sich von seiner Funktionsfähigkeit überzeugen. Dafür muß der Administrator die Option SSLDisable in die Konfigurationsdatei httpd.conf des Hauptservers einfügen, und zwar vor eventuell vorhandenen VirtualHost-Sektionen. SSLDisable schaltet SSL komplett aus. Der nächste Versuch, den Server mit den Direktiven gemäß der Beispielkonfiguration in conf/conf/httpd.conf SSL-fähig zu machen, führt zunächst beim Start zu einer Fehlermeldung (andere Konfigurationsfehler sind ebenfalls jederzeit möglich):

No SSL Certificate set for server www.domain.tld:80

Ein solches Zertifikat (was das überhaupt ist, steht in [#lit1 [1]]) muß der Administrator erzeugen. Um den Start zu erleichtern, hat Apache-SSL dem Makefile ein neues Target namens certificate hinzugefügt. Also in das src-Verzeichnis der Apache-Distribution wechseln und

make certificate

eingeben. Auf dem Bildschirm ist dann einiges zu sehen, wie Listing 1 zeigt. Zu interpretieren ist diese Ausgabe so: Das make-Kommando ruft ein Programm namens req aus der SSLeay-Distribution auf, das in den letzten sieben Zeilen einige Angaben abfragt. Aus ihnen sowie einer Datei mit einem Schlüsselpaar erzeugt das Programm einen Request (PKCS#10 base64-kodiert). In dem speziellen Fall wird darüber hinaus das Schlüsselpaar erzeugt und gemeinsam mit den Angaben im Zertifikatsformat (X.509 base64-kodiert) in die Datei ../SSLconf/conf/httpsd.pem geschrieben.

Ohne Zertifikat kein SSL

Wichtig: Beim Beantworten der Fragen ist ein Punkt unbedingt zu beachten. Der 'Common Name' muß den kompletten Namen, den Fully Qualified Domain Name (FQDN) des Servers enthalten! Der Browser vergleicht den entsprechenden Eintrag im Zertifikat mit dem Hostnamen in der URL und gibt bei Nichtübereinstimmung eine Warnung aus. Der Navigator unterstützt sogenannte Wildcardnames [#lit4 [4]] wie '*.domain.tld'. Leider gilt dies nicht für den Internet Explorer und sollte deshalb nicht verwendet werden.

Für einen Test des neuen Zertifikats erhält die Konfigurationsdatei httpd.conf folgende neue beziehungsweise geänderte Einträge:

SSLCertificateFile  
/usr/local/apache/SSLconf/conf/httpsd.pem 
SSLLogFile /dev/null 
SSLCACertificateFile  
/usr/local/apache/SSLconf/conf/httpsd.pem 
Port 443

Die Direktive SSLLogFile ist notwendig. Die Ausgabe sollte ins Nirvana geschickt werden, da sie für gewöhnlich nur die Information über die für die jeweilige Verbindung verwendeten Verschlüsselungsverfahren enthält. Falls es jedoch zu Problemen beim Zugriff auf den SSL-Server kommt, muß der Administrator diese Logdatei unbedingt untersuchen (und natürlich in der Konfiguration eine reguläre Datei angeben - wer liest schon /dev/null). Die dritte Zeile ist nur ein Workaround für einen bekannten Bug im aktuellen Patch und ohne praktische Bedeutung (zumindest nicht für jemanden, der ohne Client-Zertifikate auskommt). Die Änderung der Portnummer von 80 auf 443 ist erforderlich, da letztere beim Aufruf einer https://-Adresse standardmäßig benutzt wird. Jetzt sollte der Start des Servers funktionieren und den bekannten Inhalt des Web-Servers SSL-verschlüsselt zum Abruf bereitstellen.

Bevor der Anwender Daten vom Apache-SSL bekommt, muß er das präsentierte Zertifikat akzeptieren und dessen Gültigkeitsdauer festlegen.

Fast. Denn ein Aufruf von https://secure.domain.tld führt zu einer kleinen Enttäuschung: Der Netscape Navigator öffnet ein Fenster und teilt mit, er kenne den Herausgeber des Zertifikats nicht, wolle aber Gelegenheit geben, dieses trotzdem zu akzeptieren. Um dies zu tun, muß sich der Anwender durch mehrere kleine Dialogfenster hindurchklicken. Dabei kann er sich den Inhalt des Zertifikats genauer anschauen und entscheiden, ob er es einmalig (bis zum Beenden des Browsers) oder für die Gültigkeitsdauer des Zertifikates akzeptiert. Im letztgenannten Fall findet man das Zertifikat in der Netscape-Datenbank und kann es unter Options --> Security Preferences --> Site --> Certificates betrachten. Zum schnelleren Auffinden empfiehlt es sich, die Ansicht von 'All Certificates' auf 'Site Certificates' umzuschalten. Dann bleibt (vermutlich) als einziges Zertifikat das eigene übrig.

Wenn ein zweiter Apache-SSL-Server aufgesetzt würde, wäre es schön, dessen Zertifikat nicht wieder genauso mühselig jedem einzelnen Browser beibringen zu müssen. Das bestehende Zertifikat kann ja nicht benutzt werden, weil der Browser den Servernamen überprüft. Hier liegt eine Aufgabe für Beglaubigungsstellen oder Certification Authorities. Einige haben die Browser bereits installiert (Options --> Security Preferences --> Site Certificates, Ansicht 'Certification Authorities'), andere kann man nachträglich bekannt machen.

Eigene Certification Authority erstellen

Wie mit SSLeay Beglaubigungsstellen zu betreiben sind, stand bereits recht ausführlich in [#lit2 [2]]. Deshalb sei an dieser Stelle das Wichtigste nur kurz zusammengefaßt. SSLeay enthält ein Programm namens ca. Da dessen Handhabung etwas kryptisch ist, gibt es das Skript CA.sh, das dem Administrator einen Großteil der Fummelei mit den Optionen und Verzeichnissen abnimmt. Zuerst muß er allerdings einen Bug in der Distribution korrigieren: Mit chmod a+x CA.sh bekommt das Skript Ausführungsrechte.

Zur Bedienung: Zunächst ist die zu erstellende CA (Certification Authority) zu initialisieren. CA.sh -newca erzeugt alle nötigen Verzeichnisse und Dateien im Verzeichnis ./demoCA, in das vor dem Aufruf des Skripts zu wechseln ist. Das Skript ruft auch das bereits bekannte req-Programm auf, um den Schlüssel und das Zertifikat der Beglaubigungsstelle zu erzeugen. Hier hat der 'Common Name' keine herausragende Bedeutung, man sollte jedoch etwas Verständliches wie '_DIE_ Server CA' verwenden. Das Paßwort braucht man nur selten. Daher: aufschreiben und an einem sicheren Ort - nicht unter dem Monitor - verwahren.

Als nächstes muß das CA-Zertifikat den Browsern bekannt gemacht werden (siehe dazu auch [#lit2 [2]]), und zwar am einfachsten so:

ssleay x509 -in demoCA/cacert.pem \  
-outform DER -out demoCA/cacert.cacert-der

Nun benötigt der Web-Server noch Kenntnis über den bei der Auslieferung zu verwendenden MIME-Typ. Dafür sorgt die folgende Zeile in der Datei srm.conf:

AddType  application/x-x509-ca-cert .cacert-der

Nach dem Restart des Servers kann jeder Browser das Zertifikat der neugeschaffenen Beglaubigungsstelle von http://server/pfad/cacert.cacert-der installieren. Die gestellten Fragen ähneln denen bei der Anwahl des Servers mit selbstsigniertem Zertifikat. Der Internet Explorer muß danach neu gestartet werden, der Navigator erkennt die neue Beglaubigungsstelle gleich.

Jetzt wird es spannend: Mit Hilfe der eigenen CA soll ein Serverzertifikat unterschrieben werden. Das geschieht in mehreren Schritten. Zunächst ist ein neuer Request zu erzeugen, der im zweiten Arbeitsgang signiert wird:

CA.sh -newreq 
CA.sh -sign

Die notwendigen Eingaben bei der Ausführung der ersten Befehlszeile sind mittlerweile vertraut. Zur Erinnerung: der 'Common Name' muß den Servernamen enthalten! Die Frage nach dem Paßwort während des zweiten Befehls bezieht sich auf den Schlüssel der Beglaubigungsstelle (siehe Zettel, der entgegen dem Rat doch unterm Monitor liegt). Das Zertifikat in newcert.pem muß genauso wie der private Key in newkey.pem an die Stelle des alten Zertifikats, also beispielsweise nach /usr/local/apache/SSLconf/conf/, kopiert werden. Da Schlüssel und Zertifikat getrennt vorliegen, kommt eine neue Direktive ins Spiel:

SSLCertificateKeyFile  
/usr/local/apache/SSLconf/conf/newkey.pem

Sie war vorher nicht notwendig, da Schlüssel und Zertifikat in einer Datei enthalten waren. Nach dem Restart des Servers kommt eine neue Überraschung: Der Server verlangt ein Paßwort! An dieser Stelle kann man es zwar einfach eingeben, für einen automatischen Neustart läßt dies allerdings Probleme erahnen. Über die Behandlung dieses Falles gab es viele Diskussionen. Das Ergebnis: die einfachste und beste Lösung ist das Entfernen des Paßwortschutzes und das Vertrauen in den Schutz durch Dateirechte. Schließlich ist ein eventuell vorhandenes (Klartext-)Paßwort in Skripten auch nur durch Dateirechte geschützt. Das Entfernen geht wie folgt:

ssleay rsa -in newkey.pem -out newkey.pem

Virtuelle Hosts konfigurieren

Nun läuft der SSL-Web-Server. Und zwar parallel zum normalen, das heißt nichtverschlüsselnden Server. Das bedeutet natürlich eine Verschwendung von Ressourcen. Glücklicherweise kann Apache-SSL beide Protokolle zugleich bedienen. Dazu ist es allerdings nötig, sich etwas mit dem Konzept der virtuellen Server auseinanderzusetzen (siehe zum Beispiel [#lit3 [3]]). Ein SSL-Server wird bei Apache-SSL als virtueller Server angesehen, die Konfiguration geschieht durch

<VirtualHost meinserver:443> 
DocumentRoot ... 
</VirtualHost>

Dabei ist zu beachten, daß virtuelle SSL-Web-Server, das heißt, mehrere SSL-Server-Namen auf einer Maschine, nicht namens-, sondern nur IP-basiert eingerichtet werden können. Es ist jedoch möglich, mehrere namensbasierte virtuelle Nicht-SSL-Web-Server und einen SSL-Web-Server auf einem Rechner mit einer IP-Adresse zu betreiben. Der Grund liegt darin, daß der Name des gewünschten Web-Servers (HTTP-Host-Header) dem SSL-Server erst nach Abschluß der SSL-Verhandlungen (SSL-Handshake) zur Verfügung steht, er aber bereits während dieser Verhandlungen sein Zertifikat übermitteln muß. Und in diesem Zertifikat steht nun mal der Name des Web-Servers ... Dies gilt im übrigen nicht nur für den Apache, sondern ist eine generelle Einschränkung für jeden SSL-Web-Server.

Bleibt die Frage, was mit den übrigen SSL-Optionen aus der in der Apache-SSL-Distribution mitgelieferten httpd.conf geschehen soll. Man kann sie sowohl anfangs als auch später getrost ignorieren. Die Optionen dienen zum einen der Verwendung von Client-Zertifikaten (siehe dazu [#lit2 [2]]) und zum anderen dem Fine-Tuning der benutzten Verschlüsselungsverfahren. Beides wird in der Praxis vermutlich kaum (noch) benutzt werden. Wem die Optionen nichts sagen, kann sie getrost ignorieren. Zumindest die SSLCache-Direktiven müssen auskommentiert sein, falls, wie zu Beginn angeraten, das Session-ID-Caching in den Quellen wegdefiniert wurde.

Für die Zukunft ist zu erwarten, daß ein funktionierendes SSL-Session-ID-Caching den bislang doch eher zurückhaltenden Durchsatz bei HTTPS-Anforderungen deutlich beschleunigen wird. Der gewählte Ansatz, einen separaten Cache-Server zu verwenden, ist insbesondere für die Betreiber von Serverfarmen mit dynamischer Lastverteilung interessant, da dann die Session-Daten allen SSL-Web-Servern zur Verfügung stehen. Weiterhin laufen Arbeiten, die eine flexiblere Authentisierung auf Basis von Client-Zertifikaten erlauben. Für die Zukunft ist Apache-SSL schon heute gerüstet: SSLeay implementiert seit Version 0.9.0 TLS (Transport Layer Security, Weiterentwicklung von SSL durch die Internet Engineering Task Force IETF zu einem 'echten' Internet Standard). Davon profitiert natürlich auch Apache-SSL, wobei diese Erweiterung für den Nutzer völlig transparent bleibt und mangels Unterstützung in den aktuellen Browsern derzeit ohnehin nur mittels dem s_client-Tool von SSLeay überprüft werden kann. (bl)

Holger Reif

ist wissenschaftlicher Mitarbeiter an der TU Ilmenau. Im Fachgebiet Telematik bearbeitet er die Schwerpunkte Netzdienste, Sicherheit und elektronische Zahlungssysteme.

Literatur

[1] Holger Reif: Netzsicherheit; Schlüsselfertig; Secure Socket Layer: Chiffrieren und Zertifizieren mit SSLeay

[2] Holger Reif; Netzsicherheit; Herr der Zertifikate: Zertifikatsmanagement und Online-Beglaubigungsstellen mit SSLeay

[3] Lars Eilebrecht; Apache Web-Server; International Thomson Publishing Company; Bonn; 1997 (2. Auflage in Vorbereitung)

[4] Netscape: SSL 2.0 Certificate Usage; http://home.netscape.com/newsref/std/ssl_2.0_certificate.html#Site

[5] Apache-SSL Homepage, mittlerweile auch mit einer eigenen Mailing-Liste und einem Listarchiv