Apache

Aus Gentoo Linux Wiki

[Bearbeiten] Einleitung

Im Folgenden wird beschrieben, wie Apache als virtueller Webserver konfiguriert wird. Die Ausführungen beruhen auf apache-2.0.58. Es wird davon ausgegangen, dass auf dem Webserver vier unterschiedliche www-roots existieren: drei, die aus dem Internet abrufbar sein sollen (eine davon ist der sog. default VHOST) und eine für interne Zwecke. In Abhängigkeit von der im Browser eingegebenen URL landet man auf der zugeordneten www-root. Es ist nicht erforderlich, den apache-Dämon mehrfach mit unterschiedlichen Konfigurationsdateien (-f Option) zu starten, wie man zunächst vermuten könnte. Es ist auch nicht nötig, ihrem http-Webserver mehrere IP-Adressen zuzuordnen. Es genügt ein A- und ein CNAME-Record im DNS Ihres Serviceproviders, die auf dieselbe IP-Adresse verweisen. Um die Konfiguration vom Webserver selbst aus testen zu können, biege ich die DNS-Einträge auf 127.0.0.2/3 um. Die externen Domänen bezeichne ich mit "example1.tld" und "example2.tld", den Hostnamen jeweils mit "www". Die FQDNs lauten folglich www.example1.tld und www.example2.tld. Wenn Sie mehrere virtuelle https-Webserver betreiben wollen, benötigen Sie für jeden eine separate IP-Adresse. Um dies zu simulieren, habe ich in der hosts-Datei 127.0.0.2 und 127.0.0.3 als IP-Adressen vergeben. Im Anhang B gehe ich kurz auf die Thematik ein.

[Bearbeiten] Funktionsweise

Woher "weiß" der Webserver, über welchen FQDN er aufgerufen wurde? Die Auflösung des ersten Teils der URL, der aus Domänen- und Hostnamen besteht (=FQDN), erfolgt ja durch einen DNS-Server, der vom Client bzw. Proxy-Server angefragt wird. Er löst den FQDN in eine IP-Adresse auf, die vom Client/Proxy benötigt wird, um den Webserver zu adressieren. Man würde vermuten, dass der Webserver selbst nicht weiß, über welchen FQDN er aufgerufen wurde. Es ist jedoch anders als man denkt!

Alle modernen Browser (bzw. Proxyserver) übermitteln dem Webserver zusätzlich den FQDN, über den sie ihn adressiert haben. Diese Info kann der Webserver auswerten und den dazu passenden "virtuellen Webserver" mit seiner spezifischen www-root bereitstellen.

Vorgänge bei der Adressierung eines Webservers:

http://de.gentoo-wiki.com/Hauptseite
	->  com: Toplevel-Domäne
	->  gentoo-wiki: Domäne
	->  de: Hostname
- der DNS-Server löst den FQDN auf in: 64.193.62.26
- diese IP verwendet der Client bzw. Proxy, um den Webserver zu adressieren.
- zusätzlich zu den webspezifischen Daten (html-Seite...) wird der FQDN übermittelt

[Bearbeiten] Apache/PHP-Installation

echo "www-servers/apache mpm-prefork" >> /etc/portage/package.use
echo "dev-lang/php unicode apache2"  >> /etc/portage/package.use
emerge -av www-servers/apache
emerge -av www-apache/mod_security  # enthält zusätzliche Sicherheitsfunktionen
emerge -av dev-lang/php

APACHE2_OPTS="-D DEFAULT_VHOST -D SSL -D SSL_DEFAULT_VHOST -D PHP5 -D SECURITY"

Der komplette Inhalt der Variable "APACHE2_OPTS" wird dem Apache-Dämon als Kommandozeilenparameter übergeben. Hierdurch werden Variablen definiert (z.B. definiert "-D SSL" die Variable "SSL") , die der Apache in den Konfigurationsdateien unterhalb von /etc/apache2/ auswertet. Sie steuern den Auswertungsfluss der conf-Dateien.

Wenn Sie mod_security über "-D SECURITY" aktivieren, kann es zu Problemen mit phpmyadmin kommen. Die Lösung ist im Anhang C beschrieben.

# Kommandozeilenaufruf des Apache-Dämons
/usr/sbin/apache2 -D DEFAULT_VHOST -D SSL -D SSL_DEFAULT_VHOST ...

# In Abhängigkeit davon, ob "SSL" definiert ist, erfolgt die Abarbeitung bestimmter Anweisungen:
<IfDefine SSL>
...
</IfDefine>

rc-update add apache2 default

[Bearbeiten] x509 "self-signed" Serverzertifikat für https erstellen

Wir generieren zunächst ein "self-signed" Zertifikat, das mit dem eigenen Private-Key signiert ist. Für einen professionellen Webserver sollte das Zertifikat von einer anerkannten CA signiert sein (z.B. Thawte, VeriSign, CAcert usw.). Da deren Root-Zertifikate in den meisten Browsern vorinstalliert sind, werden alle von ihnen signierten Zertifikate von den Browsern anstandslos akzeptiert. Dies wird im Anhang beschrieben.

cd /etc/apache2/ssl
rm server*        # Standardzertifikat/-Key löschen
gentestcrt.sh
#1. Country Name             (2 letter code) []:DE
#2. State or Province Name   (full name)     []:Germany
#3. Locality Name            (eg, city)      []:Ostfildern
#4. Organization Name        (eg, company)   [Apache HTTP Server]:SK
#5. Organizational Unit Name (eg, section)   [For testing purposes only]:Systems
#6. Common Name              (eg, CA name)   [localhost]:localhost
#7. Email Address            (eg, name@FQDN) []:root@localhost
ls -l # server.crt  server.key

Wir testen die Installation:

/etc/init.d/apache2 start
ps aux | grep apache2 # Prozesse gestartet?
netstat -tulpen | grep apache2 # Port 80 und 443 geöffnet?
# im Browser eingeben: http://localhost  -> wird die Apache-Startseite angezeigt?
# im Browser eingeben: https://localhost -> prüfen Sie das Zertifikat
less /var/log/apache2/error_log     # was sagt das http-Error-Log?
less /var/log/apache2/ssl_error_log # was sagt das https-Error-Log?

[Bearbeiten] Vorarbeiten

[Bearbeiten] Einträge in hosts-Datei

Die Einträge dienen der lokalen Administration der virtuellen Webserver. Wenn Sie den Zugriff aus dem Internet vom Webserver selbst aus testen wollen, müssen Sie die Einträge auskommentieren. Voraussetzung ist, dass der Webserver seine eigenen FQDNs über einen DNS-Server auflösen kann.

127.0.0.1  localhost
127.0.0.2  www.example1.tld
127.0.0.3  www.example2.tld

[Bearbeiten] Kopieren der www-root

Standardmäßig wird die www-root unterhalb von /var/www/localhost/ angelegt. Für jeden virtuellen Webserver muss eine separate www-root angelegt werden. Die www-root unterhalb von /var/www/localhost/ bleibt für den lokalen, nicht von außen zugänglichen Webserver. Möglich wäre auch, nach dem Kopieren das Verzeichnis "localhost" zu löschen und einen symbolischen Link "localhost" zu erstellen, der auf eine der beiden externen www-roots verweist. Wenn Sie jedoch eine "private" www-root zu Testzwecken benötigen, sollten Sie das Verzeichnis "localhost" nicht löschen. Die www-root für den Default-VHOST wird dann verwendet, wenn der Webserver über keine der definierten FQDNs aufgerufen wird, also z.B. über eine URL, die die IP-Adresse des Webservers enthält (http://12.34.56.78/).

touch /var/www/localhost/htdocs/favicon.ico # Datei wird von den meisten Browsern dort erwartet
cd /var/www/
cp -a localhost example1.tld
cp -a localhost example2.tld
cp -a localhost default

[Bearbeiten] Berechtigungen auf Dateiebene

Beachten Sie, dass es einen Hauptprozess gibt, der unter "root" läuft und mehrere Sub-Prozesse, die unter "apache" laufen. Diese sind für das Abarbeiten der http(s)-Anfragen aus dem Internet verantwortlich. Wenn Sie folglich einen http-Request an einen Webserver schicken, "triggern" Sie damit einen der apache-Prozesse. Da er unter "apache" läuft, hat er die Berechtigungen, die der Benutzer bzw. die Gruppe "apache" haben. Zusätzlich zu den Verzeichnisberechtigungen, die in der httpd.conf und den eingebundenen conf-Dateien ("include...") gesetzt werden, müssen Sie auch auf der Ebene des Dateisystems dafür sorgen, dass die Berechtigungen stimmen: Benutzer/Gruppe "apache" müssen zumindest lesenden Zugriff auf Verzeichnisse und Dateien haben.

Sehr flexibel ist folgende Vorgehensweise: "apache" ist Owner, aber als Gruppe wird die neu angelegte Gruppe "webadmin1" (bzw. "webadmin2") zugewiesen. Dieser gehören nur ausgewählte Personen an. Sie erhält schreibenden Zugriff auf Verzeichnisse/Dateien. Sodann werden mindestens 3 Accounts für die Webadministratoren angelegt: "guru" soll alle www-roots administrieren können, "anton" nur example1.tld und "berti" nur example2.tld.

virt. Webserver      Ber.gruppe    Mitglieder
example1.tld         webadmin1     guru, anton
example2.tld         webadmin2     guru, berti
localhost            root          guru
default              root          guru

Im folgenden werden als Beispiel die Dateiberechtigungen für example1.tld beschrieben:

groupadd webadmin1
gpasswd -a guru apache
gpasswd -a anton apache
find /var/www/example1.tld/ -type d -exec chgrp webadmin1 {} ';' -exec chown apache {} ';' -exec chmod 570 {} ';'
find /var/www/example1.tld/ -type f -exec chgrp webadmin1 {} ';' -exec chown apache {} ';' -exec chmod u-w,g+w,o-rwx {} ';'

[Bearbeiten] Konfiguration der httpd.conf

Die meisten Einstellungen können so übernommen werden, wie sie sind. Ich möchte im folgenden nur auf einige zentrale Stellen hinweisen:

[Bearbeiten] Sperren aller nicht explizit erlaubten Verzeichnisse

Der folgende Eintrag sperrt den Zugriff auf alle Verzeichisse unterhalb des Stammverzeichnisses außer denen, die explizit erlaubt sind. Er darf auf keinen Fall fehlen!

 <Directory />
    AllowOverride None  # Einträge in .htaccess Dateien werden ignoriert
    Order deny,allow    # wenn alles verboten sein soll, immer in dieser Reihenfolge
    Deny from all
 </Directory>

[Bearbeiten] wichtige Einträge in der httpd.conf

ServerRoot "/usr/lib/apache2"  # binary Files; nicht mit www- bzw. document-root zu verwechseln!
PidFile "/var/run/apache2.pid" # enthält die Process-ID
Listen 80                      # Port; Bind-Adresse ist standardmäßig 0.0.0.0 (alle Interfaces)
#  wenn Ihr Server mehrere Netzwerkinterfaces hat, können Sie die Bind-Adresse
#  explizit angeben, z.B.  Listen 12.34.56.78:80
#  Wenn Sie den http-Server nur intern betreiben möchten, weil sie nach außen 
#  nur einen https-Server anbieten wollen, legen Sie 127.0.0.1 als Bind-Adresse fest:
#  Listen 127.0.0.1:80

[Bearbeiten] User/Group, unter der die Apache http-Prozesse laufen

Beachten Sie, dass es einen Hauptprozess gibt, der immer unter "root" läuft.

User apache
Group apache

[Bearbeiten] Webmaster Mailaccount

Der Eintrag bezieht sich auf den Default-VHOST. Für die anderen VHOSTs sollte im jeweiligen Virtual-Host-Container ein angepasster Eintrag stehen (s.u.).

ServerAdmin root@localhost

Wenn Sie die Mails an Ihren eigenen Mailaccount ("guru") umleiten wollen, müssen Sie in der Datei /etc/mail/aliases folgende Zeile eintragen und anschließend "newaliases" aufrufen.

root:      guru

[Bearbeiten] Apache-Tuning

Wenn Sie Apache mit dem USE-flag "mpm-prefork" emerged haben, können Sie in der folgenden Section Ihren Apache "tunen".

<IfModule prefork.c>
    StartServers         5
    MinSpareServers      5
    MaxSpareServers     10
    MaxClients         150
    MaxRequestsPerChild  0
</IfModule>

[Bearbeiten] Logfiles pro virtuellem Server

Jeder virtuelle Webserver sollte seine eigenen Logfiles erstellen. Dies erfolgt durch die ErrorLog- und CustomLog-Directiven innerhalb eines <VirtualHost> Containers in der Datei /etc/apache2/vhosts.d/00_default_vhost.conf. die "globale" Direktive in der httpd.conf wird verwendet für den sog. Default-VHOST (s.u.).

ErrorLog logs/error_log            # gilt für Default-VHOST
CustomLog logs/access_log common   # gilt für Default-VHOST

[Bearbeiten] Serversignatur

Apache gibt normaler Weise seine "Signatur", also seinen Namen und seine Version preis, wenn er in einen Fehler hineinläuft. Auch über Schwachstellenscanner wie z.B. "Nessus" oder "OpenVAS" kann man die Signatur herausbekommen. Wenn Sie "mod_security" emerged haben (s.o.) und es in der Datei /etc/conf.d/apache2 aktiviert haben ("-D SECURITY"), können Sie einen potentiellen Angreifer irritieren, indem sie eine leere Signatur ausgeben. Man könnte auch eine falsche Signatur angeben, aber evtl. hat dies juristische Implikationen.

ServerTokens Full
ServerSignature On
SecServerSignature " " # Signatur besteht nur aus einem Blank

[Bearbeiten] Alias bzw. ScriptAlias

Durch die Definition eines Aliases können Sie ein Verzeichnis verfügbar machen, das aus der document-root ausgeblendet ist. Angenommen, folgender Alias sei definiert:

Alias /icons/ "/var/www/localhost/icons/"

/icons/ bezieht sich auf die document-root, ist also zu vestehen als: /var/www/localhost/htdocs/icons/ Der Alias ist ähnlich wie ein symbolischer Link zu verstehen: ln -s /var/www/localhost/icons/ /var/www/localhost/htdocs/icons. Nachteil des symbolischen Links ist, dass er im Verzeichnis htdocs sichtbar ist, wogegen der Alias unsichtbar bleibt. Dies kann man leicht nachprüfen, indem man im Browser folgendes eingibt

http://localhost/         # icons-Verzeichnis nicht sichtbar
http://localhost/icons/   # icons-Verzeichnis sichtbar

Da alle Verzeichnisse gesperrt sind mit Ausnahme der explizit erlaubten, muss auch das icons-Verzeichnis freigeschaltet werden, falls dies von Ihnen gewollt ist:

<Directory "/var/www/localhost/icons/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Der Sinn der Aliase besteht wohl darin, Verzeichnisse mit eher "technischen" Inhalten aus der document-root auszublenden, da deren Inhalt den normal surfenden Anwender nicht interessiert. Sie sind jedoch trotzdem verfügbar, wenn sie in einer html-Seite direkt über den Alias-Pfad adressiert werden. ScriptAliase verhalten sich ählich wie Aliase. Die Unterschiede sind in der httpd.conf dokumentiert.

[Bearbeiten] Allow, Deny

Hierbei geht es um Zugriffskontrolle auf IP-Ebene. Oft ist es sinnvoll, bestimmte Verzeichnisse nur für localhost zugänglich zu machen. Es kann auch Situationen geben, in denen nur bestimmten Kunden, Geschäftspartnern o.Ä. Zugriff auf ein Verzeichnis gegeben werden soll.

Grundsätzlich gbt es zwei verschiedene Möglichkeiten: (1) Man nennt die berechtigten IPs und sperrt für den Rest. (2) Man nennt die verbotenen IPs und erlaubt für den Rest. Im Allgemeinen wird man sich für (1) entscheiden, weil die Anzahl der Erlaubten weitaus geringer ist als die der Verbotenen. Methode 2 ergibt nur Sinn, wenn man den Zugriff komplett verbieten will. In diesem Falle gilt: "verboten für alle und erlaubt für den Rest, also niemanden".

Beispiel für Methode 1: Sie wollen nur localhost Zugriff auf das phpmyadmin-Verzeichnis erlauben.

<Directory "/var/www/localhost/htdocs/phpmyadmin/">
    AllowOverride None
    Order allow,deny      # beachte die Reihenfolge "allow,deny"
    Allow from localhost
    Deny  from all
</Directory>

Beispiel für Methode 2: Sie wollen niemandem Zugriff auf das cgi-bin Verzeichnis geben.

<Directory "/var/www/localhost/cgi-bin/">
    AllowOverride None
    Options None
    Order deny,allow # beachte die Reihenfolge "deny,allow"
    Deny from all
    Allow from none # diese Zeile kann man weglassen, denn sie ist redundant
</Directory>

[Bearbeiten] Einbinden sonstiger conf-Dateien

In der httpd.conf stehen zwei Include-Anweisungen, durch die alle conf-Dateien unterhalb von /etc/apache2/modules.d/ und /etc/apache2/vhosts.d/ eingebunden werden. Der Inhalt dieser Dateien wird so behandelt, als ob er in der httpd.conf stehen würde.

Include /etc/apache2/vhosts.d/*.conf
Include /etc/apache2/modules.d/*.conf

[Bearbeiten] 00_default_vhost.conf

In Abhängigkeit von der Variablen "DEFAULT_VHOST" wird der Container <VirtualHost *:80> definiert. Wie oben erwähnt, wird die Variable in der Datei /etc/conf.d/apache2 definiert (-D DEFAULT_VHOST).

<IfDefine DEFAULT_VHOST>  # nur wenn DEFAULT_VHOST definiert ist,
<VirtualHost *:80>        # wird der Virtual-Host-Container definiert
                          # weil er an erster Stelle steht, ist er der Default-VHOST

Für jeden virtuellen Webserver muss ein Virtual-Host-Container definiert werden. Im ersten Virtual-Host-Container wird der sog. "Default VHOST" definiert. Dieser wird immer dann verwendet, wenn der Webserver über einen FQDN (bzw. eine IP-Adresse) adressiert wird, für den kein passender Virtual-Host-Container gefunden wird, also z.B. "http://12.34.56.78/".

####### 1. VHOST, daher Default VHOST ########
<IfDefine DEFAULT_VHOST>
<VirtualHost *:80>
    DocumentRoot "/var/www/default/htdocs/"
    <Directory "/var/www/default/htdocs">
    ...
</VirtualHost>
</IfDefine>
####### 2. VHOST für "privaten" Webserver ########
<VirtualHost *:80>
    DocumentRoot "/var/www/localhost/htdocs/"
    ServerName localhost
    Serveralias localhost
   <Directory "/var/www/localhost/htdocs">
    ...
</VirtualHost>
####### 3. VHOST für example1.tld ########
<VirtualHost *:80>
    DocumentRoot "/var/www/example1.tld/htdocs/"
    ServerName example1.tld
    Serveralias www.example1.tld
    <Directory "/var/www/example1.tld/htdocs">
    ...
</VirtualHost>
####### 4. VHOST für example1.tld ########
<VirtualHost *:80>
    DocumentRoot "/var/www/example2.tld/htdocs/"
    ServerName example2.tld
    Serveralias www.example2.tld
   <Directory "/var/www/example1.tld/htdocs">
    ...
</VirtualHost>

http://127.0.0.1/           1.VHOST (default-VHOST)
http://12.34.56.78/         1.VHOST (default-VHOST)
http://localhost/           2.VHOST
http://www.example1.tld/    3.VHOST
http://www.example2.tld/    4.VHOST

Im folgenden die Einträge für den VHOST-Container von example1.tld. Die anderen Container können analog erstellt werden.

<VirtualHost *:80>
    ServerAdmin root@example1.tld
    DocumentRoot "/var/www/example1.tld/htdocs/"
    ServerName example1.tld
    Serveralias www.example1.tld
    DirectoryIndex index.php index.html
    ErrorLog /var/log/apache2/example1.tld_error_log
    CustomLog /var/log/apache2/example1.tld_access_log combined
    <Directory "/var/www/example1.tld/htdocs">
        Options Indexes FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

[Bearbeiten] SSL erzwingen

Der Zugang über https lässt sich in jedem beliebigen Verzeichnis innerhalb einer ssl-conf-Datei erzwingen durch folgende Einträge. Im folgenden wird die höchste Sicherheitsstufe eingestellt.

SSLCipherSuite SSLv3
<VirtualHost *:443>
    ...
    <Directory "/var/www/example1.tld/htdocs">
       SSLCipherSuite SSLv3:HIGH
       SSLRequireSSL
    </Directory>
</VirtualHost>

[Bearbeiten] Debug-Modus deaktivieren

Da der Debug-Modus gewisse Schwachstellen beinhaltet, sollte er deaktiviert werden. Dies erfolgt durch folgende Einträge, am besten am Anfang jedes VHOST-Containers.

<VirtualHost *:80>
   RewriteEngine On
   RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
   RewriteRule .* - [F]
   ...

<VirtualHost _default_:443>
   RewriteEngine On
   RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
   RewriteRule .* - [F]
   ...

[Bearbeiten] Anhang A: x509-Zertifikat von professioneller CA signieren lassen

Es gibt diverse Beschreibungen im Internet, die jedoch wegen der umständlichen Syntax des openssl-Kommandos oft mühsam zu lesen sind. Ich wähle daher einen anderen Ansatz und verwende die hervorragenden Tools von "openvpn", die man auch als "Laie" gut bedienen kann. Dahinter steckt natürlich auch openssl, aber man wird von den Details verschont. Die Tools haben den weiteren Vorteil, dass man sie zum Aufbau einer eigenen CA verwenden und auch Zertifikate für die SSL-Komponenten anderer Programme generieren kann (postfix, courier-imapd usw.). Im folgenden wird beschrieben, wie man zunächst Key/Zertifikat einer eigenen CA generiert. Dieses kann zum Signieren des Webserver-Zertifikats verwendet werden. Eine eigene CA wird nicht benötigt, wenn Sie das Webserver-Zertifikat von einer allgemein anerkannten CA signieren lassen wollen, was bei einem professionellen Webserver empfehlenswert ist.

emerge -av net-misc/openvpn

Die Datei "vars" enthält grundlegende Variablen, die von den Scripten zur Zertifikatserstellung ausgewertet werden. Beachten Sie, dass es keine Variable für den "commonname" (CN) gibt. Dieser muss beim Programmaufruf als Parameter übergeben werden. Als CN müssen Sie den FQDN Ihres Webservers angeben, also z.B. "www.example1.tld"

export EASY_RSA="/etc/CertAuth"
export KEY_CONFIG="$EASY_RSA/openssl.cnf"
export KEY_DIR="$EASY_RSA/keys"
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=2048   # 1024 wäre nicht ganz so sicher
export CA_EXPIRE=9999  # ca. 27 Jahre Gültigkeit
export KEY_EXPIRE=9999
export KEY_COUNTRY="DE"
export KEY_PROVINCE="Deutschland"
export KEY_CITY="Ostfildern"
export KEY_ORG="Webservices" 
export KEY_EMAIL="root@localhost"

[Bearbeiten] Key/Zertifikat für eigene Certificate-Authority (CA) generieren

Der Private-Key der CA dient dazu, das Server-Zertifikat zu signieren. Um die Sicherheit nicht zu gefährden, muss er unter allen Umständen geheim bleiben. Er sollte sich auf einem Standalone-Rechner befinden, zu dem nur befugte Personen Zugang haben. Wenn die CA auf dem Webserver betrieben wird, sollte der Private-Key der CA durch ein Kennwort geschützt und nach Abschluss der Arbeiten auf zwei externe Medien (z.B. USB-Stick+DVDRAM) verschoben werden, die im Safe zu deponieren sind. Der Private-Key wird mit dem Kennwort verschlüsselt (Option --pass), so dass unbefugte Personen, die in seinen Besitz kommen, nichts mit ihm anfangen können.

install -d -o root -g root -m 700 /etc/CertAuth # Basisverzeichnis anlegen
cd /usr/share/openvpn/easy-rsa
cp pkitool openssl.cnf /etc/CertAuth # Dateien werden dort erwartet
source vars # nach jeder Änderung in "vars" muss die Datei "gesourced" werden.
./clean-all # evtl. vorhandene Zertifikatsdateien in KEY_DIR werden gelöscht!!
./build-ca --pass  # Zugriff auf CA-Private-Key wird durch ein Passwort geschützt
# Passwort -> kein triviales Kennwort verwenden!
# "Organizational Unit Name" -> leer lassen
ls /etc/CertAuth/keys/ca* # ca.crt (Zertifikat) ca.key (Private-Key)
openssl x509 -in /etc/CertAuth/keys/ca.crt -text -noout # Zertifikat prüfen
openssl rsa  -in /etc/CertAuth/keys/ca.key -text -noout # Key anschauen

[Bearbeiten] Key/Zertifikat des Web-Servers

Bei der Erstellung des Server-Zertifikats sollte der "Common Name" mit dem FQDN Ihres Webservers übereinstimmen. Wenn Sie mehrere virtuelle https-Webserver betreiben, benötigen Sie für jeden Server ein separates Zertifikat. Sie könnten zwar als "Common Name" die Bezeichnung "localhost" vergeben, aber bei einem professionellen Webserver macht dies keinen guten Eindruck.

Beispiel für die Signierung des Server-Zertifikats durch Ihre eigene CA (nicht empfohlen).

./build-key-server www.example1.tld # FQDN des virtuellen Servers
# "challenge password" -> leer lassen
# "An optional company name" -> leer lassen
# "Sign the certificate? [y/n]" -> y
# "1 out of 1 certificate requests certified, commit?" -> y
cp /etc/CertAuth/keys/www.example1.tld.{key,crt} /etc/apache2/ssl/

Beispiel für die Erstellung eines Certificate-Sign-Requests, das zur Signierung an eine professionelle CA geschickt werden muss. Hierbei wird der Private-Key (*.key) und ein Certificate-Sign-Requests (*.csr) erstellt. Nur der CSR geht an die CA.

./build-req www.example1.tld # FQDN des virtuellen Servers
# "challenge password" -> Kennwort festlegen, das an die CA übermittelt werden muss
cp /etc/CertAuth/keys/www.example1.tld.key /etc/apache2/ssl/
# die Datei *.csr an eine CA schicken. Vorher klären, wie das Kennwort zu übermitteln ist.
# die crt-Datei, die von der CA erstellt wird, ins Verzeichnis /etc/apache2/ssl kopieren

[Bearbeiten] Anhang B: mehrere https-VHOSTs

Leider benötigt man hierfür pro VHOST eine separate IP-Adresse. In der Datei "41_mod_ssl.default-vhost.conf" muss sodann für jeden VHOST ein VirtualHost-Container erstellt werden. Am einfachsten ist es, den Container für den Default-VHOST (<VirtualHost _default_:443>) zu kopieren, sämtliche Kommentarzeilen zu entfernen und sodann einige Werte anzupassen. Beachten Sie auch, dass Sie pro VHOST ein X509-Zertifikat benötigen und hierfür die Pfade anpassen müssen (SSLCertifikateFile...). Im folgenden als Beispiel der Container für www.example1.tld.

#### VHOST 3: example1.tld #############

# Im Endeffekt muss hier die Internet-IP-Adresse stehen.
# Es wird davon abgeraten, den DNS-Namen zu verwenden.
NameVirtualHost 127.0.0.2

<VirtualHost 127.0.0.2:443>  
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
DocumentRoot "/var/www/example1.tld/htdocs"
ServerName www.example1.tld:443
ServerAdmin root@example1.tld
ErrorLog logs/example1.tld_ssl_error_log
<IfModule mod_log_config.c>
	TransferLog logs/example1.tld_ssl_access_log
</IfModule>
SSLEngine on
SSLCipherSuite SSLv3
SSLCertificateFile conf/ssl/www.example1.tld.crt
SSLCertificateKeyFile conf/ssl/www.example1.tld.key
SSLCertificateChainFile conf/ssl/ca.crt
<Files ~ "\.(cgi|shtml|phtml|php?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/localhost/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
<IfModule mod_setenvif.c>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
</IfModule>
<IfModule mod_log_config.c>
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
</IfModule>
<Directory "/var/www/example1.tld/htdocs">
   SSLCipherSuite SSLv3:HIGH
   SSLRequireSSL
   #Options Indexes FollowSymLinks
   Options Indexes
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

</VirtualHost>

Wenn Ihr Webserver auf mehrere IP-Adressen reagieren soll, muss ein alias-Netzwerk-Interface erstellt werden. Dies geht durch einen Eintrag in der net-Datei:

config_eth0=(
    "88.88.88.1/24"
    "99.99.99.1/24"  # dieser alias erscheint bei "ifconfig" als "eth0:1"
)

[Bearbeiten] Anhang C: Probleme im Zusammenspiel von mod_security und phpmyadmin

Falls es Probleme gibt, müssen sie folgende Regeln in die Location-Direktive einschließen:

# gilt nur außerhalb von "phpmyadmin"
<Location ^*/phpmyadmin/>
   SecFilter "select.+from"
   SecFilterSelective "HTTP_CONTENT_TYPE" multipart/form-data
</Location>