Suche im Katalog
Linux Netzwerker-Handbuch

Linux Netzwerker-Handbuch


Tony Bautts, Terry Dawson & Gregor N. Purdy
3. Auflage Juli 2005
ISBN 3-89721-414-8
382 Seiten
Weitere Informationen zur gedruckten Version des Buches finden Sie unter:
www.oreilly.de/catalog/linag3ger/

Zur Übersicht aller OpenBooks


TOC PREV NEXT INDEX

Kapitel 14

Konfiguration des Apache-Webservers

Eines der momentan am weitesten verbreiteten Software-Pakete unter Linux ist der Apache-Webserver. Die Apache Software Foundation, die im Jahre 1995 als kleine Gruppe von Entwicklern unter dem Namen Apache Group ihre Arbeit begann, wurde 1999 gegründet, um den Apache HTTP-Server zu entwickeln und zu unterstützen. Der Apache-Webserver ist bekannt für seine Flexibilität und Leistungsfähigkeit. Momentan sind mehr als 25 Millionen Internet-Webserver auf seiner Grundlage in Betrieb. In diesem Abschnitt wollen wir die Grundlagen des Kompilierens und Konfigurierens eines Apache HTTP Servers erkunden und einige Optionen näher erläutern, die Ihnen bei der Sicherung und beim Betrieb dieses Systems behilflich sein können. Wir schauen uns in diesem Kapitel Apache v1.3 an, die momentan am weitesten verbreitete und unterstützte Version.

Apache-HTTPD-Server - Eine Einführung

Apache an sich ist ein einfacher Webserver. Er wurde entwickelt, um Webseiten bereitzustellen. Bei manchen kommerziellen Webservern wurde versucht, viele unterschiedliche Funktionen in ein Webserver-Produkt zu packen. Solche kombinierten Produkte weisen allerdings eine größere Anzahl von Schwachstellen auf. Die Einfachheit und das modulare Design des Apache-HTTPD-Servers sorgen für ein sichereres Produkt. Gerade im Vergleich mit anderen Webservern zeigt sich, dass der Apache-Webserver stabil und robust ist.

Das soll jetzt nicht heißen, dass Apache-Server nicht in der Lage wären, Benutzern dynamische Inhalte anzuzeigen. Es gibt viele Apache-Module, die integriert werden können, um eine fast unendliche Anzahl neuer Funktionen und Eigenschaften bereitzustellen. Zusatzprodukte wie PHP und mod_perl können verwendet werden, um leistungsfähige Webanwendungen und dynamischen Web-Inhalt zu generieren. In diesem Kapitel wollen wir uns jedoch auf die Konfiguration des Apache selbst konzentrieren. Hier besprechen wir, wie Sie einen Apache-HTTPD-Webserver kompilieren und konfigurieren, und schauen uns die verschiedenen Optionen an, mit deren Hilfe Sie einen stabilen und sicheren Webserver zusammenstellen können.

Konfigurieren und Kompilieren von Apache

Falls Apache noch nicht in Ihrer Linux-Distribution enthalten ist, dann holen Sie sich das Paket am besten von einer der vielen gespiegelten Apache-Sites. Eine Liste finden Sie auf der Website der Apache Software Foundation unter http://www.apache.org. Zurzeit gibt es zwei Zweige des Apache-HTTPD-Versionsbaums, 1.3 und 2.0. Die neue Version, v2.0, bietet neue Funktionen und Eigenschaften und wird aktiv weiterentwickelt, ist aber wahrscheinlich anfälliger für Software-Fehler und Schwachstellen. In diesem Kapitel werden wir wegen ihrer erwiesenen Zuverlässigkeit und Stabilität die neueste Version des 1.3-Zweigs behandeln. Viele der Konfigurationsoptionen sind jedoch in beiden Versionen ähnlich.

Die Software beziehen und kompilieren

Sie haben die Möglichkeit, Apache entweder im Quellformat oder im Paketformat zu erhalten. Falls Sie den Server aus einem Paket heraus installieren, erreichen Sie nicht die gleiche Flexibilität bei der Konfiguration wie bei der Kompilierung aus dem Quellcode. Bei Paketen sind im Allgemeinen die meisten gebräuchlichen Optionen bereits in den Binärdateien vorkompiliert. Falls Sie bestimmte Funktionen oder Optionen benötigen oder eine sehr minimalistische Version des Servers aufbauen wollen, sollten Sie besser vom Quellcode ausgehen.

Das Kompilieren des Apache aus den Quellen ist vergleichbar mit dem Kompilieren anderer Linux-Quellcodepakete und folgt dem Weg »configure-make-make install«. Apache besitzt viele Optionen, die während der Konfiguration der Quellen gesetzt werden müssen. Dazu gehört die Möglichkeit, die Module auszuwählen, die kompiliert oder deaktiviert werden sollen. Module sind eine großartige Methode, um Funktionalität zu Ihrem Webserver hinzuzufügen oder aus ihm zu entfernen, und decken einen großen Funktionsbereich ab - von der Performanz bis hin zur Authentifizierung und Sicherheit. Tabelle 14-1 zeigt eine der Apache-Dokumentation entnommene Liste mit einer Reihe von verfügbaren Modulen.

Tabelle 14-1
Apache-Module 
Typ
Standardmäßig aktiviert oder deaktiviert
Funktion
Einrichtung der Umgebung
 
 
mod_env
Aktiviert
Setzt Umgebungsvariablen für CGI/SSI-Skripten
mod_setenvif
Aktiviert
Setzt Umgebungsvariablen auf der Grundlage der HTTP-Header
mod_unique_id
Deaktiviert
Generiert eindeutige Identifier für die Anforderung
Entscheidungen anhand des Content-Type
 
 
mod_mime
Aktiviert
Festlegung von Content-Type/Codierung (konfiguriert)
mod_mime_magic
Deaktiviert
Festlegung von Content-Type/Codierung (automatisch)
mod_negotiation
Aktiviert
Content-Auswahl anhand der HTTP-Accept*-Header
URL-Zuordnung
 
 
mod_alias
Aktiviert
Einfache URL-Übersetzung und -Umleitung
mod_rewrite
Deaktiviert
Erweiterte URL-Übersetzung und -Umleitung
mod_userdir
Aktiviert
Auswahl der Ressourcenverzeichnisse anhand der Benutzernamen
mod_spelling
Deaktiviert
Korrektur falsch geschriebener URLs
Verzeichnisbehandlung
 
 
mod_dir
Aktiviert
Behandelt die Anfragen nach Verzeichnissen und Standarddateien
mod_autoindex
Aktiviert
Automatisierte Generierung eines Verzeichnis-Index
Zugriffskontrolle
 
 
mod_access
Aktiviert
Zugriffskontrolle (Benutzer, Host und Netzwerk)
mod_auth
Aktiviert
HTTP-Basic-Authentifizierung (Benutzer und Kennwort)
mod_auth_dbm
Deaktiviert
HTTP-Basic-Authentifizierung über Unix NDBM-Dateien
mod_auth_db
Deaktiviert
HTTP-Basic-Authentifizierung über Berkeley DB-Dateien
mod_auth_anon
Deaktiviert
HTTP-Basic-Authentifizierung für anonyme Benutzer
mod_digest
Deaktiviert
Digest-Authentifizierung
HTTP-Response
 
 
mod_headers
Deaktiviert
Beliebige HTTP-Response-Header (konfiguriert)
mod_cern_meta
Deaktiviert
Beliebige HTTP-Response-Header (Dateien im CERN-Stil)
mod_expires
Deaktiviert
Ungültigmachen von HTTP-Responses
mod_asis
Aktiviert
Reine HTTP-Responses
Skripting
 
 
mod_include
Aktiviert
Unterstützung für Server Side Includes (SSI)
mod_cgi
Aktiviert
Unterstützung für Common Gateway Interface (CGI)
mod_actions
Aktiviert
CGI-Skripten, die als interne »Handler« agieren
Interne Content-Handler
 
 
mod_status
Aktiviert
Content-Handler für den Laufzeitstatus des Servers
mod_info
Deaktiviert
Content-Handler für die Zusammenfassung der Konfiguration
Request-Protokollierung
 
 
mod_log_config
Aktiviert
Anpassbare Protokollierung von Requests
mod_log_agent
Deaktiviert
Spezialisierte HTTP-User-Agent-Protokollierung (abgelehnt)
mod_log_referer
Deaktiviert
Spezialisierte HTTP-Referrer-Protokollierung (abgelehnt)
mod_usertrack
Deaktiviert
Protokollierung von Benutzer-Klicks über HTTP-Cookies
Verschiedenes
 
 
mod_imap
Aktiviert
Unterstützung für serverseitige Imagemaps
mod_proxy
Deaktiviert
Caching-Proxy-Modul (HTTP, HTTPS, FTP)
mod_so
Deaktiviert
Dynamic Shared Object-(DSO-)Bootstrapping
Experimentell
 
 
mod_mmap_static
Deaktiviert
Caching häufig angebotener Seiten über mmap()
In der Entwicklung
 
 
mod_example
Deaktiviert
Apache-API-Demonstration (nur Entwickler)

Wenn Sie sich entschieden haben, welche Optionen Sie benutzen wollen, können Sie sie folgendermaßen zum Konfigurationsskript hinzufügen. Um ein Modul zu aktivieren, benutzen Sie:

vlager# ./configure -enable-module=modul_name

Um ein Standardmodul zu deaktivieren, können Sie folgenden Befehl einsetzen:

vlager# ./configure -disable-module=modul_name

Falls Sie eines der vorgegebenen Module aktivieren oder deaktivieren wollen, sollten Sie genau wissen, was das Modul tut. Das Aktivieren oder Deaktivieren bestimmter Module kann die Leistungsfähigkeit oder die Sicherheit nachteilig beeinflussen. Weitere Informationen über die einzelnen Module finden Sie auf der Apache-Website.

Der nächste Schritt nach der Konfiguration besteht darin, das gesamte Paket zu kompilieren. Wie bei vielen anderen Linux-Programmen wird das mit dem Befehl make erledigt. Nach der Kompilierung installiert make install den Apache in demjenigen Verzeichnis, das Sie bei der Konfiguration mit der Option -prefix= festgelegt haben.

Optionen der Konfigurationsdatei

Wenn die Apache-Software in dem von Ihnen ausgewählten Verzeichnis installiert worden ist, können Sie damit beginnen, den Server zu konfigurieren. Frühere Versionen des Apache-Servers benutzten mehrere Konfigurationsdateien. Inzwischen ist jedoch nur noch die Datei httpd.conf erforderlich. Es ist aber immer noch praktisch, mehrere Konfigurationsdateien zur Verfügung zu haben (um beispielsweise den Umstieg auf neue Versionen zu erleichtern). Die Option include ermöglicht es Ihnen, von der Hauptdatei httpd.conf aus zusätzliche Konfigurationsdateien zu lesen.

Apache enthält eine vorgegebene Konfigurationsdatei, in der die gebräuchlichsten Optionen gesetzt sind. Falls Sie es eilig haben, Ihren Server zum Laufen zu bringen, sollte diese vorgegebene Konfiguration die Anforderungen erfüllen, um Apache zu starten. Diese Konfiguration funktioniert zwar, erscheint aber vielen Administratoren nicht akzeptabel. Um die Feineinstellung der Konfiguration zu beginnen, stellen die meisten Administratoren als erste Option die IP-Adresse und die Port-Informationen auf dem Server ein.

Binden von Adressen und Ports

Listen und BindAddress sind die ersten beiden Optionen, die Sie möglicherweise ändern wollen.

# Listen: ermöglicht es Ihnen, Apache an bestimmte IP-Adressen und/oder Ports zu
# binden, anstatt die Vorgaben zu benutzen. Siehe auch die Anweisung <VirtualHost>.
#
#Listen 3000
Listen 172.16.0.4:80

Diese Konfigurationsänderung bringt den Apache-Server dazu, nur an der angegebenen Schnittstelle und dem festgelegten Port zu warten. Sie können mit der Option BindAddress auch die IP-Adresse festlegen, an die der Server gebunden wird. Mit dieser Option geben Sie nur die IP-Adresse an und nicht den Port, wie oben gezeigt.

# BindAddress: Mit dieser Option können Sie virtuelle Hosts unterstützen. Diese Anweisung
# teilt dem Server mit, an welcher IP-Adresse er lauschen soll. Sie kann entweder ein
# "*", eine IP-Adresse oder einen voll qualifizierten Internet-Domainnamen enthalten.
# Siehe auch die Anweisungen <VirtualHost> und Listen.
#
BindAddress 172.16.0.4

Optionen zur Protokollierungs- und Pfadkonfiguration

Wenn Sie Apache selbst kompilieren, haben Sie vermutlich das Installationsverzeichnis festgelegt. Ist das der Fall, dann wurden bei der Installation automatisch die Pfade für die Root-Dokumente Ihres Servers und alle Protokolldateien gesetzt. Sollten Sie das ändern wollen, sind die folgenden Optionen hilfreich:

ServerRoot
Die Position der Hauptkonfigurations- und Protokolldateien des Servers
DocumentRoot
Die Position Ihrer HTML-Dokumente oder anderer Web-Inhalte

Standardmäßig schreibt der Apache seine Protokolle in einen Pfad unterhalb des Root-Pfades des Servers. Falls Sie auf Ihrem Server einen anderen Ort haben, an dem Sie Protokolle sammeln, und die Pfade der Protokolldateien entsprechend anpassen wollen, müssen folgende Optionen geändert werden:

CustomLog
Die Position Ihrer Zugriffsprotokolldatei
ErrorLog
Die Position Ihrer Fehlerprotokolldatei

Es gibt noch einige weitere nützliche Optionen, die gesetzt werden können, wenn Sie die Protokollierungseinstellungen auf dem Apache konfigurieren:

HostnameLookups
Teilt Apache mit, ob er die Namen der protokollierten IP-Adressen ermitteln soll. Sie sollten diese Option besser ausgeschaltet lassen, da sich die Protokollierung verlangsamen kann, falls der Server versucht, alle Namen aufzulösen.
LogLevel
Diese Option teilt Apache mit, wie viele Informationen in die Protokolldateien geschrieben werden sollen. Standardmäßig ist die Option auf warn gesetzt, mögliche Werte sind debug, info, notice, warn, error, crit, alert und emerg. Jeder höhere Level schreibt weniger Informationen in das Protokoll.
LogFormat
Mit dieser Option können Administratoren entscheiden, in welchem Format die Protokolle geschrieben werden. Elemente wie das Datum, die Zeit und die IP-Adresse können entsprechend dem gewünschten Format neu angeordnet werden. Die vorgegebenen Einstellungen werden normalerweise nicht geändert.

Server-Identifikationsstrings

Normalerweise ist der Apache sehr freundlich und liefert anfragenden Benutzern eine Vielzahl von Informationen über sich selbst. Dazu gehören die Versionsnummer, der virtuelle Hostname, der Name des Administrators usw. Sicherheitsbewusste Administratoren wollen diese Informationen möglicherweise deaktivieren, da sie Angreifern nützlich sind, um den Server auszuspähen. Das Folgende ist zwar nicht unbedingt die allerbeste Methode, um Ihre Site zu schützen, allerdings werden potenzielle Angreifer, die automatische Werkzeuge zum Scannen des Systems benutzen, dadurch behindert. Die folgenden beiden Konfigurationsoptionen können Ihnen dabei helfen, die Menge an Informationen zu begrenzen, die Ihr Server enthüllt:

ServerSignature
Wenn diese Option aktiviert ist, fügt der Server den servergenerierten Seiten eine Zeile hinzu, die alle Versionsinformationen enthält.
ServerTokens
Wenn Sie diese Option auf Prod setzen, wird der Apache daran gehindert, seine Versionsnummer bekannt zu geben.

Performance-Einstellungen

Sites haben immer unterschiedliche Ansprüche an die Performance. Bei vielen Sites liefern die Voreinstellungen, die der Apache mitbringt, die angeforderte Leistung. Sites, die stark ausgelastet sind, müssen jedoch Änderungen an der Konfiguration vornehmen, um die Leistungsfähigkeit zu verstärken. Die folgenden Optionen dienen der Performance-Einstellung eines Servers. Weitere Informationen über dieses Thema finden Sie auf der Website der Apache Software Foundation.

Timeout
Die Anzahl der Sekunden, bevor der Apache Empfangs- und Sendeanforderungen wegen Zeitüberschreitung (Timeout) abbricht.
KeepAlive
Aktivieren Sie diese Option, wenn Sie persistente Verbindungen aktivieren wollen. Werte für die Option sind on oder off.
MaxKeepAliveRequests
Setzen Sie diese Option auf die Anzahl der Keep-Alive-Anforderungen, die der Server in persistenten Verbindungen zulassen soll. Wenn Sie hier einen höheren Wert einstellen, verbessert sich möglicherweise die Performance.
KeepAliveTimeout
Die Anzahl der Sekunden, die der Apache auf eine neue Anforderung aus der gerade aktiven Sitzung wartet.
Min/MaxSpareServers
Diese Optionen können verwendet werden, um einen Pool aus freien Servern anzulegen, die Apache benutzen kann, wenn er ausgelastet ist. Bei größeren Sites soll hier möglicherweise ein höherer Wert als die Vorgabe eingestellt werden. Allerdings ist für jeden freien Server mehr Speicher auf dem Server erforderlich.
StartServers
Diese Option teilt Apache mit, wie viele Server beim ersten Aufruf gestartet werden sollen.
MaxClients
Diese Option kann ein Administrator dazu benutzen, um die Anzahl der Client-Sitzungen auf einem Server zu begrenzen. Die Apache-Dokumentation warnt davor, diesen Wert zu niedrig anzusetzen, da dadurch die Verfügbarkeit nachteilig beeinflusst werden könnte.

Starten und Stoppen des Apache mit apachectl

Falls Sie sicher sind, dass Ihr Server nun fertig konfiguriert ist, und Sie ihn laufen lassen wollen, müssen Sie apachectl bemühen, ein Programm, das im Apache enthalten ist und das sichere Starten und Stoppen des Servers möglich macht. Folgende Optionen stehen für apachectl zur Verfügung:

start
Startet den Standard-HTTP-Server.
startssl
Startet zusätzlich zum normalen Server die SSL-Server.
stop
Beendet den Apache-Server.
restart
Sendet dem laufenden Server ein HUP-Signal.
fullstatus
Gibt den vollständigen Status des Webservers aus, erfordert aber mod_status.
status
Zeigt eine kürzere Version der obigen Statusausgabe. Verlangt mod_status.
graceful
Sendet ein SIGUSR1 an den Apache-Server.
configtest
Durchsucht die Konfigurationsdatei nach Fehlern.

Es ist zwar nicht zwingend erforderlich, Apache mit apachectl zu starten, es wird jedoch empfohlen und stellt auch die einfachste Methode dar. Mit apachectl wird auch das Herunterfahren der Server-Prozesse einfacher und effizienter.

VirtualHost-Konfigurationsoptionen

Eine der leistungsfähigsten Funktionen von Apache ist die Fähigkeit, mehrere Webserver auf einer Maschine auszuführen. Das geschieht mit Hilfe der VirtualHost-Funktion, die in der Datei httpd.conf zu finden ist. Es gibt zwei Arten von virtuellen Hosts, die konfiguriert werden können - benannte virtuelle Hosts und IP-basierte virtuelle Hosts. Bei benannten virtuellen Hosts können Sie mehrere TLDs auf einer einzigen IP-Adresse benutzen, während bei IP-basierten virtuellen Hosts nur ein virtueller Host pro IP-Adresse möglich ist. In diesem Abschnitt zeigen wir Ihnen für beide Techniken einige Beispiele und stellen Ihnen die gebräuchlichsten Konfigurationsoptionen vor.

IP-basierte virtuelle Hosts

Diejenigen von Ihnen, die nur eine Site betreuen müssen oder die für jede zu betreibende Site eine eigene IP-Adresse haben, werden IP-basierte virtuelle Hosts für die beste Konfigurationslösung halten. Betrachten Sie das folgende Beispiel, bei dem die virtuelle Brauerei beschließt, eine Website für die virtuelle Weinkellerei aufzusetzen. Im Folgenden sehen Sie die mindestens erforderliche Konfiguration, die in die Datei httpd.conf eingefügt werden müsste, um die neue Website anzulegen.

Listen www.virtualvineyard.com:80
.
.
<VirtualHost www.virtualvineyard.com>
ServerAdmin webmaster@vbrew.com
DocumentRoot /home/www/virtualvineyard.com
ServerName www.virtualvineyard.com
ErrorLog /var/www/logs/vvineyard.error_log
TransferLog /var/www/logs/vvineyard.access_log
</VirtualHost>

Wahrscheinlich wollen Sie dann auch noch sicherstellen, dass www.virtualvineyard.com zu Ihrer /etc/hosts-Datei hinzugefügt wurde. Das ist notwendig, weil der Apache beim Start eine IP-Adresse für diese Domain nachschlagen muss. Sie können sich ganz und gar auf Ihr DNS verlassen. Falls allerdings Ihr DNS-Server aus irgendwelchen Gründen nicht zur Verfügung steht, wenn der Webserver neu gestartet wird, fällt Ihr Webserver aus. Sie können jedoch die IP-Adresse Ihres Servers am Anfang Ihrer Konfiguration im Tag <VirtualHost> fest codieren. Das scheint effizienter zu sein, falls Sie allerdings die IP-Adresse Ihres Webservers ändern wollen, müssen Sie auch die Apache-Konfigurationsdatei anpassen.

Zusätzlich zu den im Beispiel aufgeführten Konfigurationsoptionen können auch alle Optionen, die weiter vorn in diesem Kapitel besprochen wurden, zu den VirtualHost-Gruppen hinzugefügt werden. Damit erhalten Sie maximale Flexibilität für alle Ihre separaten Webserver.

Namensbasierte virtuelle Hosts

Die Konfiguration der namensbasierten virtuellen Hosts entspricht in etwa derjenigen im vorherigen Beispiel, nur dass mehrere Domains unter einer einzigen IP-Adresse vorgehalten werden können. Zwei Dinge müssen Sie bei dieser Funktion jedoch beachten. Das erste - möglicherweise der größte Nachteil - ist, dass SSL nur mit einer einzigen IP-Adresse benutzt werden kann. Das ist kein Problem bei Apache, sondern eher bei SSL und der Art und Weise, wie Zertifikate funktionieren. Der zweite potenzielle Nachteil besteht darin, dass einige ältere Webbrowser, etwa diejenigen ohne HTTP 1.1-Spezifikation, nicht funktionieren. Das liegt daran, dass beim Betrieb namensbasierter virtueller Hosts der Client im HTTP-Request-Header den Server darüber informiert, welche Site er besuchen möchte. Bei nahezu allen Webbrowsern, die in den letzten Jahren veröffentlicht wurden, ist allerdings HTTP 1.1 implementiert, so dass dies für die meisten Administratoren kein Problem darstellt.

Als Beispielkonfiguration verwenden wir dasselbe Beispiel wie weiter vorn in diesem Kapitel. Dieses Mal besitzt die virtuelle Brauerei jedoch nur eine öffentliche IP-Adresse. Sie müssen Apache zuerst davon in Kenntnis setzen, dass Sie einen namensbasierten virtuellen Host verwenden. Anschließend geben Sie Einzelheiten über Ihre Site bekannt, wie in diesem Beispiel gezeigt.

NameVirtualHost 172.16.0.199
<VirtualHost 172.16.0.199>
ServerName www.vbrew.com
DocumentRoot /home/www/vbrew.com
</VirtualHost>
<VirtualHost 172.16.0.199>
ServerName www.virtualvineyard.com
DocumentRoot /home/www/vvineyard.com
</VirtualHost>

Aus Gründen der Übersichtlichkeit wurden weitere Optionen weggelassen. Bei Bedarf können jedoch alle zuvor besprochenen Optionen hinzugefügt werden.

Apache und OpenSSL

Nachdem Sie Ihre Apache-Webserver-Konfiguration eingerichtet und getestet haben, wollen Sie als Nächstes vermutlich eine SSL-Seite konfigurieren. Es gibt viele Gründe, SSL einzusetzen: vom Schutz webbasierter E-Mail-Clients bis zum Anbieten sicherer E-Commerce-Transaktionen. Innerhalb von Apache gibt es zwei Optionen zum Bereitstellen von SSL, Apache-SSL und mod_ssl. In diesem Abschnitt konzentrieren wir uns auf das ältere und gebräuchlichere mod_ssl.

Wie bei jeder SSL-basierten Anwendung sind auch hier Zertifikate erforderlich. Diese bilden die Grundlage, auf der die Vertrauensbeziehung zwischen Client und Server aufgebaut wird. Das bedeutet, falls Sie eine Site für ein Unternehmen vorhalten, werden Sie wahrscheinlich ein Zertifikat haben wollen, das von einer dritten Partei wie Verisign oder Thawte unterzeichnet wurde. Da diese Zertifikate nicht kostenlos sind, können Sie auch - sofern Sie nicht kommerzielle Ziele verfolgen - Ihr eigenes Zertifikat generieren. Der Nachteil dieser Methode besteht in Folgendem: Wenn Clients auf Ihre Site zugreifen, wird eine Fehlermeldung erzeugt, die ihnen mitteilt, dass Ihr Zertifikat nicht vertrauenswürdig ist, weil es nicht von einer dritten Partei signiert wurde. Das bedeutet, dass sie sich durch die Fehlermeldungen klicken sowie entscheiden müssen, ob sie Ihrem Zertifikat vertrauen oder nicht. In diesem Beispiel geben wir Ihnen Konfigurationsbeispiele für Administratoren, die ihre eigenen Zertifikate anlegen. Alternativ bietet die Organisation cacert.org kostenlose Zertifikate für Einzelpersonen.

Generieren eines SSL-Zertifikats

Um eine SSL-Sitzung aktivieren zu können, müssen Sie zuerst ein Zertifikat erzeugen. Dazu überprüfen Sie zunächst, ob OpenSSL installiert ist. Sie finden es unter http://www.openssl.org sowohl im Quell- als auch im Binärformat. Viele Linux-Distributionen enthalten dieses Paket bereits, so dass Sie es nicht extra installieren müssen. Sobald Sie OpenSSL installiert oder die Installation überprüft haben, können Sie damit fortfahren, das erforderliche SSL-Zertifikat anzulegen.

Der erste Schritt dabei besteht darin, eine Anforderung zum Signieren des Zertifikats (Certificate Signing Request) zu erzeugen. Sie müssen eine temporäre PEM-Passphrase und einige Informationen über Ihre Site eingeben:

vlager# openssl req -config openssl.cnf -new -out vbrew.csr
Using configuration from openssl.cnf
Generating a 1024 bit RSA private key
...............................++++++
....++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) [  ]:Berkeley
Organization Name (eg, company) [Internet Widgits Pty Ltd]:www.vbrew.com
Organizational Unit Name (eg, section) [  ]:
Common Name (eg, YOUR name) [  ]:www.vbrew.com
Email Address [  ]:webmaster@vbrew.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password [  ]:
An optional company name [  ]:

Im nächsten Schritt entfernen Sie die PEM-Passphrase für den privaten Schlüssel aus Ihrem Zertifikat. Dadurch kann der Server neu starten, ohne dass das Kennwort eingegeben werden muss. Paranoide Administratoren können diesen Schritt überspringen. Sollte der Server dann allerdings ausfallen, muss er manuell neu gestartet werden.

vlager # openssl rsa -in privkey.pem -out vbrew.key
read RSA key
Enter PEM pass phrase:
writing RSA key

Nachdem Sie die Passphrase entfernt haben, müssen Sie Ihre Zertifikatsdatei signieren. Das geschieht mit Hilfe der Option x509 mit OpenSSL:

apache ssl # openssl x509 -in vbrew.csr -out vbrew.cert -req -signkey vbrew.key -days 365
Signature ok
subject=/C=US/ST=California/L=Berkeley/O=www.vbrew.com/CN=www.vbrew.com/Email=webmaster@vbrew.com
Getting Private key

Sobald das abgeschlossen ist, können Sie Ihr Zertifikat benutzen. Sie sollten die Zertifikatsdateien in Ihr Apache-Verzeichnis kopieren, damit der Webserver darauf zugreifen kann.

mod_ssl für Apache kompilieren

Falls Sie Apache wie im früheren Beispiel in diesem Kapitel aus den Quellen kompiliert haben, müssen Sie in die Apache-Quellen einen Patch einspielen und die Quellen neu kompilieren, damit Sie mod_ssl benutzen können. Haben Sie jedoch Apache aus einem Binärpaket für Ihre Linux-Distributionen installiert, dann stehen die Chancen gut, dass das Modul bereits einkompiliert wurde. Um festzustellen, ob Sie eine erneute Kompilierung durchführen müssen, prüfen Sie mit dem folgenden Befehl, welche Module in Apache enthalten sind:

vlager # /var/www/bin/httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_access.c
mod_auth.c
mod_setenvif.c

In diesem Fall ist mod_ssl nicht enthalten. Wir müssen es also herunterladen und in unseren Apache-Server kompilieren. Glücklicherweise ist das nicht so schwierig, wie es vielleicht klingt. Die Quelle für mod_ssl finden Sie unter http://www.modssl.org. Sie müssen sie zusammen mit den Quellen für OpenSSL auspacken. Um uns die Sache zu erleichtern, haben wir alle drei Quellbäume im gleichen Verzeichnis untergebracht. Wenn Sie alles ausgepackt haben, können Sie fortfahren. Zuerst müssen Sie den Übersetzungsprozess von mod_ssl konfigurieren:

vlager # ./configure --with-apache=../apache_1.3.28 --with-openssl=../openssl-0.9.6i
Configuring mod_ssl/2.8.15 for Apache/1.3.28
+ Apache location: ../apache_1.3.28 (Version 1.3.28)
+ Auxiliary patch tool: ./etc/patch/patch (local)
+ Applying packages to Apache source tree:
o Extended API (EAPI)
o Distribution Documents
o SSL Module Source
o SSL Support
o SSL Configuration Additions
o SSL Module Documentation
o Addons
Done: source extension and patches successfully applied.

Angenommen, Sie haben Ihr OpenSSL aus den Quellen kompiliert und es geht mit Ihrem Apache-Quellverzeichnis konform, dann können Sie Apache folgendermaßen konfigurieren und kompilieren:

vlager # cd ../apache_1.3.28
vlager # SSL_BASE=../openssl-0.9.6i ./configure -prefix=/var/www --enable-module=ssl
Configuring for Apache, Version 1.3.28
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.8.15
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
+ SSL library path: /root/openssl-0.9.6i
+ SSL library version: OpenSSL 0.9.6i Feb 19 2003
+ SSL library type: source tree only (stand-alone)
+ enabling Extended API (EAPI)
+ using system Expat
+ checking sizeof various data types
+ doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/regex
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/ssl

Wenn die Konfiguration der Quellen abgeschlossen ist, können Sie Apache mit make install neu kompilieren. Sie könnten außerdem den Befehl httpd -l erneut ausführen, um zu überprüfen, ob mod_ssl in den Apache kompiliert wurde.

Änderungen an der Konfigurationsdatei

Es sind nur ein paar kleinere Änderungen erforderlich. Am einfachsten aktivieren Sie SSL in Apache, indem Sie die VirtualHost-Anweisungen benutzen, die wir bereits besprochen haben. Zuerst jedoch müssen Sie außerhalb des VirtualHost-Abschnitts am Ende Ihrer Konfigurationsdatei die folgenden SSL-Anweisungen hinzufügen:

SSLRandomSeed startup builtin
SSLSessionCache None

Nun müssen Sie Ihre VirtualHost-Konfiguration kompilieren, um die SSLEngine zu aktivieren. Fügen Sie - wiederum in die Datei httpd.conf - die folgenden Zeilen ein:

<VirtualHost www.vbrew.com:443>
SSLEngine On
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!SSLv2:+EXP:+eNULL
SSLCertificateFile conf/ssl/vbrew.cert
SSLCertificateKeyFile conf/ssl/vbrew.key
</VirtualHost>

Dieser Abschnitt aktivierte die SSLEngine und konfigurierte die Verschlüsselungsprogramme. Sie können selbst auswählen, welche Sie zulassen und welche Sie verbieten wollen. Das »!« wird für Einträge benutzt, die ausdrücklich verboten sind, »+« steht für solche Einträge, die erlaubt sind. Falls Sie Ihre Zertifikate in einem anderen Verzeichnis gespeichert haben, müssen Sie die notwendigen Änderungen an den SSLCertificateFile- und KeyFile-Einträgen vornehmen. Weitere Informationen über die Optionen, die mit mod_ssl zur Verfügung stehen, finden Sie in der Dokumentation auf der mod_ssl-Website.

Fehlerbehebung

Da Apache-Konfigurationen sehr komplex sein können, ist es nicht unwahrscheinlich, dass sich Probleme einschleichen. Dieser Abschnitt benennt einige der häufiger vorkommenden Fehler und zeigt Lösungen für diese Probleme.

Testen der Konfigurationsdatei mit apachectl

Die Administratoren haben Glück, denn Apache enthält ein Programm zum Prüfen der Konfiguration, das Änderungen testet, die an einer Konfiguration vorgenommen wurden, bevor diese Änderungen auf einen laufenden Server übertragen werden. Findet das Programm Fehler, dann präsentiert es Ihnen eine Fehlerdiagnose. Betrachten Sie das folgende Beispiel:

vlager # ../bin/apachectl configtest
Syntax error on line 985 of /var/www/conf/httpd.conf:
Invalid command 'SSLEgine', perhaps mis-spelled or defined by a module not included in the server configuration

Das Konfigurationstestwerkzeug hat einen Fehler in Zeile 985 gefunden. Es stellt sich heraus, dass die SSLEngine-Anweisung falsch geschrieben wurde. Dieses Prüfwerkzeug findet Syntaxfehler, was ja schon einmal eine große Hilfe ist. Administratoren sollten dieses Programm immer ausführen, bevor sie ihre Server stoppen und neu starten.

Die Option configtest löst jedoch nicht alle Ihre Probleme. Zahlendreher in einer IP-Adresse, ein falsch geschriebener Domainname oder auskommentierte Dinge, die eigentlich notwendig sind, bestehen den Test, verursachen aber Probleme auf dem laufenden Server.

Seite nicht gefunden

Der Fehler »Seite nicht gefunden« oder »Page not found« ist sehr allgemein und kann unter verschiedenen Umständen auftreten. Dadurch teilt Apache Ihnen mit, dass es die Seite nicht finden oder lesen kann. Falls Sie eine Fehlermeldung dieser Art erhalten, überprüfen Sie zuerst alle Ihre Pfade. Denken Sie daran, dass Sie mit Apache in einer Umgebung mit virtuellen Verzeichnissen arbeiten. Falls Sie Verweise auf Dateien außerhalb dieser Struktur haben, ist es sehr wahrscheinlich, dass der Server nicht in der Lage ist, sie anzubieten. Darüber hinaus müssen Sie die Berechtigungen der Dateien überprüfen und sicherstellen, dass der Benutzer, dem der Webserver-Prozess gehört, sie lesen kann. Dateien, die root oder einem anderen Benutzer gehören und die auf den Modus 700 (lesen/schreiben/ausführen durch den Benutzer) gesetzt sind, verursachen Fehler, weil der Benutzer mit dem Webserver-Prozess sie nicht lesen kann.

Pfadnamen werden ebenso wie Domainnamen häufig falsch geschrieben. configtest findet zwar möglicherweise einige davon, aber sicher nicht alle. Ein Tippfehler kann zum Ausfall einer kompletten Site führen. Überprüfen Sie alles doppelt, falls Sie ein Problem haben.

SSL-Probleme

Falls Ihr SSL-Server nicht funktioniert, gibt es eine ganze Reihe von Dingen, die schief gegangen sein können. Liefert Ihr Server keine Seiten aus, sollten Sie die Datei error_log überprüfen. In ihr finden Sie oft eine Menge Hinweise zur Fehlerbehebung. So lieferte etwa unser Beispiel-Webserver keine SSL-Seiten, unverschlüsselte Seiten dagegen wurden ohne Probleme ausgeliefert. Eine Überprüfung von error_log ergab Folgendes:

[Wed Aug 6 14:11:33 2003] [error] [client 10.10.0.158] Invalid method in request
\x80L\x01\x03

Diese Art von Fehler ist sehr verbreitet. Die ungültige Anfrage ist der Client, der versucht, eine SSL-Sitzung auszuhandeln. Aus irgendeinem Grund liefert der Webserver jedoch nur unverschlüsselte Seiten an den SSL-Port. Wir können dies sogar überprüfen, indem wir den Browser an Port 443 richten und eine normale HTTP-Sitzung initiieren. Die Ursache für diesen Fehler liegt darin, dass der Server glaubt, ihm wäre nicht gesagt worden, dass er die SSLEngine aktivieren soll.

Um dieses Problem zu beheben, müssen Sie sicherstellen, dass Sie folgende Zeile in Ihrer httpd.conf-Datei stehen haben:

SSLEngine On

Sie sollten außerdem den VirtualHost-Eintrag prüfen, den Sie für den SSL-Server angelegt haben. Falls es einen Fehler in der IP-Adresse oder dem DNS-Namen gibt, unter dem der Server angelegt werden sollte, gibt der Server diese Art von Fehler aus. Sehen Sie sich den folgenden Auszug aus Ihrer Konfigurationsdatei an:

<VirtualHost www.vbrew.cmo:443>
SSLEngine On
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP:+eNULL
SSLCertificateFile conf/ssl/vbrew.cert
SSLCertificateKeyFile conf/ssl/vbrew.key
</VirtualHost>

Ein Tippfehler in der VirtualHost-Anweisung hat den Server zu dem Versuch veranlasst, in der Top-Level-Domain .cmo zu starten und nicht in .com. Natürlich erkennt Apache das nicht als Fehler und tut genau das, wozu Sie ihn aufgefordert haben.

Andere Probleme mit SSL hängen wahrscheinlich damit zusammen, wo die Schlüssel abgelegt wurden, sowie mit den Berechtigungen. Achten Sie darauf, dass der Server weiß, wo sich die Schlüssel befinden, und dass sie von den entsprechenden Einheiten gelesen werden können. Falls Sie einen selbst unterzeichneten Schlüssel verwenden, dann denken Sie außerdem daran, dass manche Clients aufgrund ihrer Konfiguration das Zertifikat nicht akzeptieren und deshalb Fehler verursachen. Ist das der Fall, dann konfigurieren Sie entweder Ihre Client-Workstations entsprechend neu oder erwerben Sie ein signiertes Zertifikat einer Drittpartei.


TOC PREV NEXT INDEX


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2005, O'Reilly Verlag GmbH & Co. KG