Webserver Apache
Willemers Informatik-Ecke
Wer einen Webserver auf der Basis von Windows aufsetzt, demonstriert damit, dass er Angst hat, sich mit Linux zu befassen. Ein Linux-Server ist lizenzfrei, wartungsärmer und schon allein deshalb performanter, weil nicht ständig ein Virenscanner mitläuft. Darüber hinaus sind die Software-Quellen sicher und ein Update deutlich unproblematischer.

Da es also keinen sachlichen Grund für einen Windows-Server gibt, befasst sich diese Seite auch nicht mit Apache in einer Windows-Umgebung.

Installation

Jedes Linux hat Apache in seinem Repository. Da das Repository die denkbar sicherste Quelle ist, sollte der Apache von dort installiert werden.

Debian, Ubuntu und Linux Mint verwenden das Tool apt für die Installation seiner Pakete. Dazu benötigt man root-Rechte. Das Apache-Paket heißt apache2. Vor der eigentlichen Installation stellt man sicherheitshalber mit apt update die Konsistenz der Paketliste zwischen Computer und Repository sicher. 

# apt update
# apt install apache2
Im weiteren Verlauf der Seite wird von einer Debian-Installation ausgegangen, die auch der unter einem Ubuntu-Server entspricht. Andere Linux-Versionen unterscheiden sich in Details.

Red Hat und CentOS

Red Hat und CentOS verwenden das Tool yum und das Apache-Paket heißt dort httpd, weil Apache ein HTTP-Server (oder Daemon) ist. 
yum install httpd
Entsprechend heißt das Konfigurationsverzeichnis bei Red Hat und CentOS auch /etc/httpd.

SUSE und OpenSUSE

Installation unter SUSE

Test und Neustart

Ob der Apache auf dem lokalen Computer läuft, lässt sich einfach durch einen dort gestarteten Browser, beispielsweise Firefox prüfen.

Bei Änderungen an der Konfiguration muss der Apache neu gestartet werden. Dazu verwendet man das Kommando: 

# systemctl reload apache2
Im Allgemeinen ist es auch noch möglich, die System-V-Startskripte zu verwenden. 
/etc/init.d/apache2 restart

Websites konfigurieren

Die Konfiguration eines Apachen erfolgt im Verzeichnis /etc/apache2. Dort befinden sich nach der Installation typischerweise zwei Dateien, eine für HTTP-Seiten une eine für HTTPS-Seiten, also Seiten, bei denen die Übertragung mit einem Zertifikat verschlüsselt wird.

Apache kann mehrere Domänen auf einem Server betreiben. Für jede Präsenz wird typischerweise eine eigene Konfigurationsdatei erstellt. und im Verzeichnis /etc/apache2/sites-available abgelegt.

Konfigurationsdateien anlegen und scharfstellen

Damit die Konfigurationsdatei wirksam wird, muss sie im Verzeichnis /etc/apache2/sites-enabled erscheinen. Anstatt die Dateien zu verschieben, wird üblicherweise ein symbolischer Link auf die jeweilige Datei des Verzeichnisses sites-available angelegt. Änderungen in einer der beiden Verzeichnisse gelten so für beide und die Konfiguration der Site läuft nicht auseinander. Ein solcher symbolischer Link wird wie folgt angelegt: 
cd /etc/apache2/sites-enabled
ln -s ../sites-available/meineseite
Die Struktur der Verzeichnisse sieht folgendermaßen aus: 
/etc/apache2
        +--- sites-enabled
        +--- sites-available
Dateien in den enabled-Verzeichnissen sind normalerweise symbolische Links auf Dateien im parallelen available-Verzeichnis.

Struktur einer Konfigurationsdatei

Für jede Website wird sinnvollerweise eine eigene Konfigurationsdatei angelegt. Sie beginnt mit dem Schlüsselwort VirtualHost. Ihm folgen der Asterix, ein Doppelpunkt und die Portnummer. 
<VirtualHost *:80>
    ... Direktiven ...
</VirtualHost>

<VirtualHost *:80>
    # ServerName www.meinedomain.de
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    ... Direktiven ...
</VirtualHost>
Die Direktive DocumentRoot legt fest, wo sich die HTML-Dateien befinden. Ihr folgt also der Pfad, typischerweise liegt er unterhalb von /var/www.

Jeder Pfad kann einzeln konfiguriert werden. Dazu wird ein Bereich mit dem Schlüsselwort Directory gekennzeichnet. Es folgt der Pfad des Aufrufs. Erfolgt der Aufruf per www.firma.de/produkte, kann der Bereich der Produkte gesondert behandelt werden, indem Folgendes definiert wird: 

<VirtualHost *:80>
    ServerName www.meinedomain.de
    DocumentRoot /var/www/html
    <Directory /produkte>
        AllowOverride All
        ... Direktiven ...
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    ... Direktiven ...
</VirtualHost>
In diesem Fall liegt unterhalb des Verzeichnisses die Direktive AllowOverride, die es ermöglicht, .htaccess-Dateien in diesem Verzeichnis abzulegen.

Der Verzeichnisname /produkte bezieht sich auf die URL, würde also hier auf www.meinedomain.de/produkte wirken.

Direktiven

An verschiedenen Stellen der Konfiguration können Direktiven gesetzt werden, wie in den bisherigen Beispielen bereits erkennbar ist. Hier sind einige gänge Direktiven und ihre Bedeutung.

Module

Apache kann durch Module erweitert werden. Am bekanntesten dürfte das Interpretermodul für die Sprache PHP sein.

Module müssen manchmal aus dem Repository nachgeladen werden, wenn sie nicht zum Standardlieferumfang von Apache gehören.

Für das Modul von PHP, wie für alle anderen Module, gibt es je eine Datei mit der Endung .conf und eine Datei mit der Endung .load. Die erstere konfiguriert das Modul und ist modulspezifisch, die zweite Datei gibt an, wo sich das Modul befindet und wie es geladen wird.

Neben dem PHP-Modul existiert noch das SSL-Modul (ssl.conf und ssl.load), das explizit freigeschaltet werden muss.

Im Falle von SSL muss das Modul auch zunächst aktiviert werden. Dazu dient der Befehl a2enmod. Erst dann öffnet Apache den Port 443. 

# # a2enmod ssl
# systemctl restart apache2

Auch die Module werden in zwei Verzeichnissen enabled und available abgelegt und werden analog zu sites verwaltet. 

/etc/apache2
        +--- mods-enabled
        +--- mods-available

Private Konfiguration mit .htaccess

Wurde in der Konfiguration die Direktive AllowOverride freigeschaltet, kann im Datenverzeichnis eine Datei .htaccess abgelegt werden, die Konfigurationen auf Verzeichnisebene erlaubt. Das ist insbesondere interessant, wenn man eine Webpräsenz bei einem Provider hat, dessen Apache sich der eigenen Konfiguration entzieht.

Eine .htpasswd-Datei wird mit dem Befehl htpasswd gepflegt. Der folgende Befehl trägt einen Benutzer paul in der Datei /var/www/sicher/.htpasswd ein. Er fordert anschließend die doppelte Eingabe des Passworts auf der Konsole ein. 
htpasswd -c /var/www/sicher/.htpasswd paul

Mehrere Domänen auf einem Server

Machen wir uns nichts vor: Viele Websites sind so langweilig, dass sie niemand sehen will. Die Website des Amtes für Untergangsfragen der Deutschen Marine ist vermutlich seit ihrer Entstehung nur dreimal besucht worden. Es wäre recht unsinnig, für solche Domänen jeweils einen eigenen Host aufzustellen. Damit Provider mehrere solcher Domänen verwalten können, bietet Apache das Konzept des virtuellen Hosts.

Damit die Aufrufe unterschiedlicher Domänen auf einen einzigen Host zusammenlaufen, brauchen sie die Unterstützung des Domain Name Service (DNS). Dieser kann mehrere Domänen auf einen Server umleiten.

Zum Ausprobieren müssen Sie nicht unbedingt einen DNS-Server aufsetzen. Es reicht, ein paar Manipulationen an der Datei /etc/hosts auszuführen.

Die vom Client angeforderte Domain liest der Server aus der HTTP-Anfrage. Er wird also die IP-Adresse der Anfrage nicht auswerten müssen.

Einrichten der Konfigurationsdateien

Das kann man ausprobieren. Neben der ersten Domain (etwa willemer.edu) soll es eine zweite Domain (etwa willi.edu) geben.

Zunächst wird eine Datei namens \datei{willi.edu} im Verzeichnis \datei{sites-available} erstellt. Sie soll sich um die neue Domain \url{willi.edu} kümmern. Dazu kopiert man die Datei \datei{000-default.conf} und passt sie an: 

<VirtualHost www.willi.edu:80>
        ServerAdmin webmaster@localhost
        ServerName  www.willi.edu
        DocumentRoot /var/www/willi
        ...
Um die Seite zu aktivieren, kennt Apache den Befehl a2ensite. Er erzeugt einen symbolischen Link im Verzeichnis sites-enabled. 

# a2ensite willi.edu.conf
Die Wirkung ist leicht zu überprüfen, indem man in das Verzeichnis hineinschaut. 
# ls -l /etc/apache2/sites-enabled/
insgesamt 0
lrwxrwxrwx ... 000-default.conf -> ../sites-available/000-default.conf
lrwxrwxrwx ... willi.edu.conf -> ../sites-available/willi.edu.conf
Man kann den benötigten symbolischen Link auch ohne a2ensite selbst von Hand setzen. 
# cd /etc/apache2/sites-enabled/
# ln -s ../sites-available/willi.edu.conf
Zu guter Letzt ist es nicht verkehrt, den Apachen zu bitten, seine Konfigurationsdateien noch einmal zur Kenntnis zu nehmen. 
systemctl reload apache2

Erstellen der Inhalte

Als Verzeichnis für die eigentlichen HTML-Dateien steht in der Konfigurationsdatei als DocumentRoot der Pfad \datei{/var/www/willi}. Das Verzeichnis muss existieren, also erzeugen wir es und legen eine HTML-Datei hinein. 
# cd /var/www
# mkdir willi
# vi willi/index.html
In die Datei kommt irgendetwas, was im Browser deutlich anzeigt, dass die Domain wwww.willi.edu aufgerufen wurde. Das könnte die folgende Datei index.html erreichen.

Damit der Webserver die Dateien auch alle lesen kann, ist es sinnvoll, diese ihm zu schenken. Dazu wird unter Linux gern der Befehl chown für change owner verwendet. Die Option -R bewirkt, dass alle Dateien und Verzeichnisse unterhalb des Arguments einbezogen werden. 

chown -R www-data /var/www/meinedomain

<h2>willi.edu</h2>

Testen der Konfiguration

Damit die beiden Webseiten www.willemer.edu und www.willi.edu von demselben Apache betreut werden, muss die Namensauflösung beider auf dieselbe IP-Adresse zeigen. Das wird in der Praxis mit dem Domain Name Service (DNS) realisiert. Für die Testphase reicht es aber völlig, die Datei /etc/hosts des Clients zu manipulieren. 
# /etc/hosts
...
192.168.109.199   www.willemer.edu www.willi.edu
Wird anschließend im Browser einmal www.willemer.edu und einmal www.willi.edu eingegeben, sollten jeweils eine andere Webseite erscheinen.

HTTPS-Der verschlüsselte Zugriff

Bei der HTTP-Kommunikation über den Port 80 werden alle Daten im Klartext übertragen. Das ist insbesondere bei der Eingabe von Passwörtern nicht gut. Für einen verschlüsselten Transport wird HTTPS verwendet, das über den Port 443 kommuniziert.

HTTPS bietet gegenüber HTTP zwei wichtige Eigenschaften:

Beides wird über Zertifikate erreicht, die zur vollständigen Funktion bei einer CA bestätigt werden müssen. Für die ersten Tests oder für die Verwendung im Intranet, kann man die CA-Zertifizierung selbst übernehmen, muss aber diese bei allen beteiligten Browsern eintragen.

Verschlüsselung über das Zertifikat

Zertifizierung der Zertifikate

Damit der Client die Echtheit des Zertifikats prüfen kann, müsste er jedes Zertifikat eines Webservers weltweit mit sich führen. Das ist nicht machbar.

Wie bei einem Personalausweis, der durch den Stempel des Ausstellerlandes autorisiert wird, geht man bei Zertifikaten vor. Es gibt es Zertifikatsautorisierungsstellen (CA - Certificat Authority), die Zertifikate quasi zertifizieren.

Dazu sendet man sein Zertifikat an die CA, die mit ihrem privaten Schlüssel das Zertifikat autorisiert. Parallel macht die CA-Stelle ihren öffentlichen Schlüssel verfügbar. Beispielsweise enthält ein Browser bereits eine Bibliothek der relevanten CA-Stellen. Zeigt der öffentliche CA-Schlüssel, dass das Zertifikat von einer bekannten CA-Stelle autorisiert wurde, kann der Client das Zertifikat bedenkenlos verwenden.

Das CA-Zertifikat wird nicht zur Verschlüsselung verwendet, sondern um das Zertifikat zu autorisieren, das zur Verschlüsselung verwendet wird. Wenn die CA also betrügerisch wäre, käme sie dennoch nicht an die verschlüsselten Daten.

Für das eigene Netzwerk kann man das CA-Zertifikat auch selbst erstellen. Das ist bei Intranet-Anwendungen durchaus sinnvoll, weil die meisten Browser auf Zertifikate ohne bekannte CA sehr aufgeregt reagieren, was sich leicht auf die Anwender überträgt, die mit Warnungen überhäuft werden.

Browser-Einbindung

Beim Firefox wird der öffentliche CA-Key über die drei waagerechten Striche, die neuerdings ein Menü darstellen sollen und dann über folgende Schritte eingefügt.
  1. Einstellungen|Erweitert|Zertifikate
  2. Dort wählen Sie den Button Zertifikate anzeigen.
  3. Klicken Sie auf den Reiter Zertifizierungsstellen.
  4. Dort wählen Sie den Button Importieren. In der nun erscheinenden Dateiauswahlbox können Sie die Datei auswählen.

Webserver mit kombinierten Schlüsseln

Bei einigen Webservern kann der öffentliche CA-Schlüssel nicht separat eingebunden werden. In diesen Fällen ist es möglich, den öffentlichen CA-Schlüssel direkt an das öffentliche Zertifikat anzuhängen. Das funktioniert mit einem einfachen Linux-Standardbefehl: 
cat ca-pub.pem >> zertifikat-pub.pem

Konfigurieren des Apachen für HTTPS

Damit der Apache HTTPS verwendet, muss er den Port 443 betreuen und das Modul ssl installiert haben. In der VirtualHost-Konfiguration müssen die Pfade zu den Zertifikaten liegen und natürlich muss festgelegt werden, wo die HTML-Dateien liegen sollen.

Port 443 und Modul ssl

Zunächst wird überprüft, ob der Apache den Port 443 vielleicht bereits bedient. Zum Scannen offener Ports dient das Tool nmap, das allerdings erst installiert werden muss. 

# apt update
# apt install nmap
# nmap 127.0.0.1
Sollte der Port 443 nicht auftauchen, kontrolliert man, ob es in der Datei /etc/apache2/ports.conf eingetragen ist. Das sieht normalerweise so aus: 
<IfModule mod_gnutls.c>
        Listen 443
</IfModule>
Schließlich wird das Modul ssl aktiviert. Dann muss Apache neu gestartet werden. 
# a2enmod ssl
# systemctl restart apache2

Verweis auf die Zertifikate in der VirtualHost-Konfiguration

Für den Apachen liegt nach der Installation bereits eine Default-Konfiguration für SSL unter /etc/apache2/sites-available/default-ssl.conf vor. Diese Konfiguration muss nur angepasst und aktiviert werden. Abgesehen von Kommentaren enthält sie folgende Einträge: 
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    </VirtualHost>
</IfModule>
Zunächst prüft die Konfiguration, ob das Modul ssl installiert ist. In der Folgezeile der Konfiguration wird der Zugriff für den Port 443 zugelassen, dem Standard-Port von HTTPS. Die anderen Einträge unterscheiden sich nicht von der Standardkonfiguration, nur die mit SSL beginnenden Direktiven sind neu. Sie sollten auf die erstellten Dateien verweisen. 
SSLCertificateFile    /etc/apache2/ssl/zertifikat-pub.pem
SSLCertificateKeyFile /etc/apache2/ssl/zertifikat-priv.pem
...
SSLCertificateChainFile: /etc/apache2/ssl/ca-pub.pem
Natürlich müssen zuvor die Dateien in die angegebenen Verzeichnisse geschoben werden.

Die so angepasste Datei liegt im Verzeichnis sites-available, muss aber noch im parallelen Verzeichnis sites-enabled auftauchen. Das macht man nach guter UNIX-Sitte mit einem symbolischen Link: 

cd /etc/apache2/sites-enabled
ln -s ../sites-available/default-ssl.conf 001-ssl.conf
Das Apache-Modul für mod_ssl wird, falls noch nicht vorhanden, installiert. 
apt install libapache2-mod-gnutls
Das Modul SSL wird freigeschaltet. 
a2enmod ssl
Nach allen Konfigurationsänderungen muss der Apache neu gestartet werden: 
systemctl restart apache2