Virtuelle Gastgeber

Wie so oft im Leben, wird man auch beim eigenem Webserver Opfer seiner Möglichkeiten. Hat man es erst einmal geschafft, den Apachen zum Heulen zu bringen, finden sich schnell weitere Wünsche. Gerade im privatem Bereich möchte man für mehrere Domains (Warum man die braucht? Weil es geht.) nicht auch mehrere Server einrichten.

Braucht man auch nicht, da es dem Apachen virtuos gelingt, sich virtuell zu vermehren. Das Konzept dahinter nennt sich virtual host und ein solcher ist im Handumdrehen angelegt. Da sich virtual hosts aus einer Kombination von Domain und Port zusammensetzen, kommt es häufig vor, dass eine Domain in zwei virtual host Konfigurationen vertreten ist, nämlich in einer für http (Port 80) und in einer für https (Port 443), wobei für http meist nur eine Weiterleitung auf https eingestellt ist.

Um das Thema abzurunden (oder um sich ganz den Möglichkeiten hinzugeben) ist es zudem interessant, wie man solche virtuellen Hosts für die Öffentlichkeit erreichbar macht. Dafür braucht man für den Privatanschluss einen sogenannten DynDNS-Service, der die Domain mit den an solchen Anschlüssen üblicherweise wechselnden IP-Adressen verlinkt, sowie ein öffentlich vertrauenwürdiges Zertifikat für den https Host.

Eine einfache virutal host Konfiguration sieht z. B. so aus:

sudo nano /etc/apache2/sites-available/your doamin.de.conf
<VirtualHost *:80>
    ServerName yourdomain.de
    ServerAlias www.yourdomain.de
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/yourdomain.de
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<Directory /var/www/yourdomain.de>
    AllowOverride All
</Directory>

MIt der angesprochenen Weiterleitung von http auf https würde der „Directory“-Block wie folgt abgewandelt:

<Directory /var/www/yourdomain.de>
    RewriteCond %{SERVER_NAME} =yourdomain.de
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</Directory>

Damit eine solche Konfiguartion auch aktiviert (enabled) wird, braucht es noch folgenden Befehl:

sudo a2ensite yourdomain.de

Nach einem obilgatorischen Reload sollte der Apache dem virtuellen Gastgeber nun beim Servieren helfen.

Damit nun https funktioniert, braucht der jeweilige virtuelle host nun noch ein Zertifikat. Dieses sollte idealerweise von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt worden sein. Die Zertifikate solcher Zertifizierungstellen (CAs) sind nämlich in den Betreibssystemen der jeweiligen Clients installiert (z. B. Windows, Android etc.), so dass alle Zertifikate die diese CAs ausstellen, ebenfalls als vertrauenswürdig gelten. Ist man im Besitz eines Domainnamens und weist diesem per DynDNS die jeweils aktuelle IP-Adresse zu, braucht man nur noch eine Möglichkeit für ein solches Setting ein passendes Zertifikat ausstellen zu lassen. Dies funktioniert problemlos und simpel mit dem certbot Tool von Let’s encrypt. Unter Debian funktioniert dies so:

sudo apt install letsencrypt
sudo certbot

Das Tool findet den passenden Weg für die Zertifikatausstellung und richtet das Zertifikat auch schon auf den jeweiligen virtuellen hosts ein.


Beitrag veröffentlicht

in

von

Schlagwörter:

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert