SSL-Verschlüsselung mit Apache
Sichere Verbindung
Geschützte Kommunikation
SSL-Verschlüsselung mit Apache
Eine per Verschlüsselung geschützte Datenübertragung zwischen Webserver und Browser des Anwenders ist nicht nur für Banken und Online-Shops eine feine Sache. Prinzipiell ist eine gegen unbefugte Einblicke abgesicherte Kommunikation immer sinnvoll, wenn sensible Daten ausgetauscht werden.
Entgegen der allgemeinen Auffassung ist es inzwischen nicht mehr schwer, den Web-Auftritt ganz oder in Teilen in einer Variante mit sicherer Übertragung zur Verfügung zu stellen. Internet Professionell beschreibt, wie Sie dies für einen Webserver unter Suse Linux 9.1 bewerkstelligen. Der dabei verwendete Weg setzt eine SSH-Verbindung zur Kommandozeile des Servers als Superuser mit Root-Rechten voraus.
Vorbereitungen
SSL-Verschlüsselung mit Apache
Die gute Nachricht zuerst: Wie bei den meisten Distributionen ist auch bei Suse Linux 9.1 bereits alles vorhanden, was für den Betrieb mit Verschlüsselung notwendig ist. Die schlechte Nachricht: Nicht jeder Provider richtet alle benötigten Pakete ein. Sollten Sie feststellen, dass auf dem Server etwas nicht wie beschrieben funktioniert, stellen Sie sicher, dass die Installation vollständig ist.
Dies erreichen Sie am einfachsten, indem Sie Yast 2 aufrufen und dort im Menü Software die Option Software installieren oder löschen wählen. In der daraufhin angezeigten Übersicht wählen Sie das Filtermenü und darin dessen Option Selektionen. Es erscheint eine Liste der von Suse vorgefertigten Paketgruppen. Ist der Eintrag Einfacher Webserver mit Apache2 mit einem vorangestellten »i« gekennzeichnet, ist alles in Ordnung. Andernfalls bewegen Sie den Markierungsbalken auf diesen Eintrag und drücken [+]. Übernehmen Sie die Wahl und starten die Installation. Am besten führen Sie nach dem Abschluss der Installation noch ein Online-Update durch. Weder die Installation noch das Online-Update überschreiben vom Anwender geänderte Dateien. Sie können die Schritte daher problemlos auf einem arbeitenden System durchführen.
Schnelleinstieg
SSL-Verschlüsselung mit Apache
Für den Betrieb eines mit Verschlüsselung arbeitenden Webservers gibt es prinzipiell zwei Möglichkeiten: Entweder wird jeweils ein eigener Webserver für normale sowie einer für sichere Verbindungen gestartet, oder es werden entsprechende virtuelle Server definiert. Suse bedient sich der zweiten Variante und liefert eine passende Beispielkonfiguration mit. Diese findet sich in der Datei vhost-ssl.template im Verzeichnis /etc/apache2/vhosts.d. Um sie zu aktivieren, genügt es, die Datei umzubenennen.
cd /etc/apache2/vhosts.d
cp vhost-ssl.template sslhost.conf
Dies allein reicht jedoch nicht, um den sicheren Server zu starten. Zusätzlich ist die Datei /etc/sysconfig/apache2 zu editieren. Zum einen ist die Parameterliste des Schlüsselworts APACHE_MODULES um den Wert ssl zu erweitern. Zusätzlich müssen Sie den Wert SSL der Variablen APACHE_SERVER_FLAGS zuweisen.
Nun fehlen noch die benötigten Zertifikate. Unter dem in diesem Beitrag verwendeten Suse Linux 9.1 gestaltet sich das einfach. Für einen Test genügt es, das Hilfsprogramm gensslcert aufzurufen, um ein Dummy-Zertifikat zu generieren. Per rcapache2 restart starten Sie den Webserver neu und übernehmen die Änderungen.
Ein erster Abruf der so erzeugten Webseite durch die Eingabe von https://
Darüber hinaus fällt auf, dass nicht die Inhalte einer bereits angelegten Webpräsenz dargestellt werden, sondern die Standardseite einer Apache-Installation.
Feintuning
SSL-Verschlüsselung mit Apache
Letzteres lässt sich einfach beheben: Es genügt, in der Datei sslhost.conf den Parameter des Schlüsselworts DocumentRoot auf das gewünschte Verzeichnis zu setzen und den Server neu zu starten.
Etwas kniffliger gestaltet sich das Ausmerzen der anderen beiden Probleme. Diese hängen direkt mit dem SSL-Zertifikat zusammen. Wird gensslcert ohne Parameter aufgerufen, generiert es ein Zertifikat, das auf den aktuellen Hostnamen ausgestellt ist, und signiert dieses auch selbst. In der Regel entspricht aber der Hostname des Servers nicht dem Namen der darauf beheimateten Webdomain. Die logische Konsequenz: Ein neues Zertifikat für die richtige Domain muss her.
Genau das leistet ein erweiterter Aufruf von gensslcert:
gensslcert -n *.testlab.ipro \
-e webmaster@testlab.ipro \
-c DE -l Munich -s Bavaria \
-o "VNU Business Publications"
Dieser Aufruf ändert neben der Domain, für die das Zertifikat ausgestellt wird, gleich noch einige andere Werte. So setzt er die E-Mail-Adresse des zuständigen Webmasters, legt die Landeskennung DE für Deutschland fest, stellt die Organisation über den Parameter -o ein und definiert Bundesland (-s) und Ort (-l). Von Bedeutung ist auch, dass als Domain nicht www.testlab.ipro ? der für das Beispiel gewählte URL des Webservers ? angegeben ist, sondern das Wildcard-Zeichen zum Einsatz kommt. Durch diesen Trick gilt das Zertifikat für alle Hosts in der Domain testlab.ipro.
Nach einem Neustart beweist ein Test, dass dieser noch die nicht vertrauenswürdige Zertifizierungsstelle bemängelt. Um diese letzte Hürde zu überwinden, reichen zumindest für einen Server, der öffentlich zugänglich sein soll, die Bordmittel nicht aus.
Voraussetzung für einen reibungslosen Aufbau einer geschützten Verbindung ist, dass das vom Server verwen-dete Zertifikat von einer Stelle signiert wurde, die der Browser als vertrauenswürdig einstuft. Das bedeutet, dass Unternehmen wie Verisign (www.verisign.com), Thawte (www.thawte.com) oder IKS (www.iks-jena.de) das Zertifikat signieren müssen, wofür in der Regel eine Gebühr fällig wird.
Anders sieht es aus, wenn nur eine überschaubare Zahl von Anwendern mit dem Server Daten austauscht. Hier bietet es sich an, das vom Server selbst signierte Zertifikat in den Browser zu importieren. Bei Mozilla geschieht dies über die Option Zertifikat dauerhaft akzeptieren. Benutzer des Internet Explorer klicken in der Detail-Ansicht des Zertifikats auf Zertifikat importieren.
Problemzone virtuelle Hosts
SSL-Verschlüsselung mit Apache
Mit dem beschriebenen Verfahren lässt sich eine per SSL-Verschlüsselung arbeitende Webseite realisieren. Das mag ausreichen, wenn parallel zum Angebot unter http://www.xyz.de ein geschütztes Pendant unter https://www.xyz.de erreichbar sein soll. Was aber, wenn auf dem Server mehrere, über unterschiedliche Domains erreichbare Web-Auftritte gehostet werden?
Vielen schießt gleich der Gedanke durch den Kopf, weitere virtuelle Hosts anzulegen. Schließlich ist auch die bereits laufende HTTPS-Seite als virtueller Host angelegt. Leider lassen sich virtuelle Hosts auf SSL-Basis nicht so einfach realisieren. Die Ursache liegt im Ablauf des Verbindungsaufbaus begründet. Bevor eine Anfrage an den Webserver gesendet wird, handeln SSL und Browser zuerst die Verschlüsselungsalgorithmen aus und durchlaufen die Authentifizierungsroutinen. Erst dann übermittelt der Browser dem Server den Request.
Ergo kann das SSL-Modul vorab überhaupt nicht wissen, auf welche Seite der Anwender zugreifen möchte. Um aber die Authentifizierung durchführen zu können, benötigt das SSL-Modul die Zertifikatinformationen, und die wiederum sind in der Definition der Website gespeichert. Kurz: ein typisches Henne-Ei-Problem. Das SSL-Modul behilft sich nun wenig elegant: Es verwendet die Zertifikatinformationen, die in der ersten mit SSL arbeitenden Seitenkonfiguration des Webservers gefunden wird. Mit anderen Worten: Ganz gleich wie viele virtuelle Hosts mit SSL-Unterstützung Sie definieren, die Anwender landen immer auf derselben Seite. Nämlich der, die in der Konfiguration an erster Stelle steht.
Variante 1: alternative Ports
SSL-Verschlüsselung mit Apache
Einen Ausweg aus der Misere stellt die Verwendung alternativer Portnummern für weitere, per SSL erreichbare virtuelle Hosts dar. Das Setup gestaltet sich vergleichsweise einfach. Erzeugen Sie zunächst im Verzeichnis /etc/apache2/vhosts.d eine Kopie der Datei sslhost.conf:
cd /etc/apache2/vhosts.d
cp sslhost.conf sslhost2.conf
Legen Sie nun ein neues Verzeichnis für den Content dieses Web-Angebots an und erzeugen ein neues Zertifikat:
mkdir /srv/www/sslhost2
echo "" > /srv/www/sslhost2/index.php
gensslcert -n *.mydom.test \
-e webmaster@mydom.test -c DE \
-l Munich -s Bavaria -o "SSL Host 2"\
-C sslhost2
Wichtig ist dabei der letzte Parameter (-C sslhost2). Er bewirkt statt der normalerweise erzeugten Zertifikate ca.crt und server.crt das Anlegen der Dateien sslhost2-ca.crt und sslhost2-server.crt.
Öffnen Sie die zuvor durch das Kopieren erstellte Datei sslhost2.conf mit einem Editor. Ändern Sie die Port-Definition hinter dem Schlüsselwort VirtualHost auf einen anderen Wert, beispielsweise 666, und passen Sie die Namen der Zertifikate an:
SSLCertificateFile /etc/apache2/ssl.crt/sslhost2 -server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/sslhost2 -server.key
Um auch das Stammverzeichnis für die Webdokumente auf das zuvor angelegte Directory zu setzen, ändern Sie den Parameter des Schlüsselworts DocumentRoot auf /srv/www/sslhost2.
Damit der Webserver zukünftig auf dem Port 666 auf SSL-Daten lauscht, ist eine abschließende Änderung der Datei /etc/apache2/listen.conf nötig. Tragen Sie hier zusätzlich zur bereits vorhandenen Anweisung Listen 443 in einer neuen Zeile den Befehl Listen 666 ein. Speichern Sie die angepasste Konfiguration und starten Sie den Webserver neu. Ein Aufruf des URLs https://mydom.test:666 bewirkt die Ausgabe der PHP-Statusinformationen, da das Index-Dokument per echo-Befehl mit eben dieser Funktion versehen wurde.
Variante 2: Mod_Rewrite
SSL-Verschlüsselung mit Apache
Der Nachteil des eben beschriebenen Verfahrens ist, dass in dem Aufruf der per SSL geschützten Seiten stets der Port mit anzugeben ist. Das sieht nicht nur hässlich aus, auch für die Anwender ist dies eine unkomfortable Methode.
Eine elegantere Lösung bietet der Ansatz über das Apache-Modul Mod_Rewrite. Mit dessen Hilfe lassen sich URLs der Form subsite.domain.de in das Format https://domain.de/subsite/ umwandeln. Um mehrere virtuelle Hosts mit SSL-Verbindungen auszustatten, müssen dann nur noch die entsprechenden Unterverzeichnisse angelegt werden. Für das folgende Beispiel sollen alle Aufrufe von https:// www.mydom.test nach https://testlab.ipro/mydom umgeleitet werden. Zum Umschreiben des URLs dienen die folgenden Befehle, die in der Datei .htaccess im Verzeichnis /srv/www/htdocs ? dem Stammverzeichnis des normalen HTTPS-Servers ? zu hinterlegen sind:
RewriteEngine on
RewriteCond %{HTTP_HOST}
^www\.mydom\.test(.*)$
RewriteRule ^(.+)
https://mydom.testlab.ipro/$1
RewriteCond %{HTTP_HOST}
!^testlab\.ipro(.*)$
RewriteCond %{HTTP_HOST}
^[^.]+\.testlab\.ipro(.*)$
RewriteCond %{HTTP_PORT} !^80$
RewriteRule ^(.+) %{HTTP_HOST}/$1 [C]
RewriteRule
^([^.]+)\.testlab\.ipro(.*)
https://testlab.ipro/$1$2 [L,R]
Damit der Webserver diese Regeln auch ausführt, ist ein Befehlsblock in der ursprünglichen SSL-Hostdatei /etc/apache2/vhosts.d/sslhost.conf vor dem Schlüsselwort einzufügen:
Options +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Jetzt ist nur noch dafür zu sorgen, dass beim Start des Webservers das Modul Mod_Rewrite geladen wird. Dazu fügen Sie in der Datei /etc/sysconfig/apache2 in die Parameterliste des Schlüsselworts APACHE_MODULES den Wert rewrite an einer beliebigen Stelle ein. Haben Sie die Änderungen gespeichert, erstellen Sie noch das benötigte Verzeichnis und erzeugen in diesem wieder eine einfache Index-Datei:
mkdir /srv/www/htdocs/mydom
echo "" >
/srv/www/htdocs/mydom/index.php
Nach einem Neustart des Servers leitet ein Aufruf der Site https://www.mydom.test ab sofort automatisch weiter auf https://testlab.ipro/mydom und zeigt die Statusinformationen von PHP an. Dieses Schema können Sie für eine beliebige Anzahl von Domains verwenden.
Im Vergleich zur Variante mit eigenen Port-Adressen für die einzelnen Webbereiche hat dieses Verfahren allerdings den Nachteil, dass es für alle Websites stets dasselbe Zertifikat verwendet.
Ausblick
SSL-Verschlüsselung mit Apache
Selbstverständlich gibt es eine weitere Möglichkeit, SSL-gesicherte Webserver für mehrere Domains bereitzustellen. Statt jeder Domain einen eigenen Port oder ein eigenes Unterverzeichnis zuzuweisen, können Sie je Domain eine eigene IP-Adresse verwenden. Allerdings sind zusätzliche Adressen nicht bei jedem Hoster zu bekommen.
Sie können mit SSL und den Zertifikaten noch wesentlich mehr machen, als dieser Beitrag vermitteln kann. So lässt sich der Zugriff auf ganze Web-Auftritte oder auch einzelne Bereiche auf Personen begrenzen, die über ein spezielles, von Ihnen ausgestelltes Zertifikat verfügen. Auch die Art der Verschlüsselung lässt sich vorschreiben. Derartige Konfigurationen sind allerdings recht komplex. Einen Einstieg in die Materie vermittelt die Dokumentation, die bei der Installation von Apache mit auf die Platte übertragen wird.