Lösung für Hetzners Subdomain-Problem

Ich hatte euch ja gestern erzählt, dass Hetzner für jede Subdomain mit eigenem Document-Root Setup-Gebühren abkassieren will, wenn man für diese SSL aktivieren will. Das wollte ich mir nicht einfach so gefallen lassen. Deshalb habe ich eine Lösung für dieses Problem gesucht und gefunden. Aber fangen wir mal vorne an.

Für jede Domain und jede Subdomain kann man beim Hetzner-Webhosting ein eigenes Startverzeichnis (die sogenannte "Document-Root") festlegen. Dazu loggt man sich in die konsoleH ein, besucht die "Domain Extras" und geht dort bei den "Einstellungen" auf "Serverkonfiguration". Nun sieht man eine Liste der verfügbaren Ordner, wobei neben jedem Ordner drei Symbole zu sehen sind. Klickt man nun auf das kleine Häuschen (das sich dann grün färbt), ändern man den Ordner, aus dem Die Dateien für die entsprechende Domain ausgelesen werden.

Hetzner Document Root

Um das Root-Verzeichnis einer Subdomain zu ändern, besucht ihr statt der "Serverkonfiguration" einfach den Menüpunkt "Subdomains". Dort könnt ihr dann den Namen der Subdomain und den Root-Ordner der Subdomain eintragen. Natürlich könnt ihr den Root-Ordner einer Subdomain auch später noch ändern.

Hetzner Document Root (Subdomains)

Die Document Root wird dafür eingesetzt, jeder Domain und jeder Subdomain ihr eigenes Verzeichnis zu geben, damit die Dateien von DomainA und DomainZ nicht wild durcheinander gemischt in ein und demselben Ordner liegen müssen. Die Document Root selber wird normalerweise direkt in die Konfiguration des Webservers (z.B. des Apache) eingetragen.

Wie wir nun gehört haben, kriegt es Hetzner nicht hin, Subdomains über ein einzelnes SSL-Zertifikat abzuhandeln, wenn diese sich in verschiedenen Root-Verzeichnissen befinden. Meine Idee war deshalb, allen Subdomains das gleiche Wurzelverzeichnis zuzuweisen und mich dann selber um das Emulieren von individuellen Root-Verzeichnissen zu kümmern. Mit ein klein wenig mod-rewriting war das überhaupt kein Problem! In dem gleichen Schritt konnte ich zudem eine Merkwürdigkeit von Hetzners Infrastruktur beseitigen. Hier jedoch erst einmal der Quelltext einer beispielhaften .htaccess-Datei. Diese muss in das tiefstmögliche Verzeichnis "public_html" gelegt werden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
RewriteEngine on
Options +FollowSymLinks

RewriteBase /

RewriteCond %{HTTP_HOST} ^(.+)\.www(.+)\.your\-server\.de$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [L,R=301]

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [L,R=301]

RewriteCond %{HTTP_HOST} ^domain\.test$ [NC]
RewriteCond %{REQUEST_URI} !^\/domain(\/.*)?$ [NC]
RewriteRule ^(.*)$ /domain/$1

RewriteCond %{HTTP_HOST} ^subdomaina\.domain\.test$ [NC]
RewriteCond %{REQUEST_URI} !^\/subdomaina(\/.*)?$ [NC]
RewriteRule ^(.*)$ /subdomaina/$1

RewriteCond %{HTTP_HOST} ^subdomainz\.domain\.test$ [NC]
RewriteCond %{REQUEST_URI} !^\/subdomainz(\/.*)?$ [NC]
RewriteRule ^(.*)$ /subdomainz/$1

Damit dieser Aufbau funktioniert, muss die Domain und alle Subdomains auf das gleiche Document Root zeigen (in diesem Fall "public_html"). Im Grunde genommen machen wir dann anschließend nichts weiter, als uns selbst um die Zuweisung des tatsächlichen Document Roots zu kümmern. Wir ziehen diese Aufgabe also aus der Konfiguration des Webservers heraus. Dadurch sollte es möglich sein, für alle Subdomains ein und dasselbe Zertifikat zu verwenden (und damit nur einmal das Setup für die Domain zu bezahlen).

Für die Leute, die sich nicht mit mod_rewrite auskennen, hier eine kurze Erklärung des Quelltextes:

  • Mit den ersten drei Zeilen aktivieren wir eine Funktion des Webservers, mit dem URLs umgeschrieben werden können. Mit anderen Worten: Die URL, die man dann als Nutzer aufruft, ist in Wahrheit garnicht die URL, die zum Schluss verarbeitet wird.
  • Mit dem ersten darauf folgenden Block kümmern wir uns um eine Unart von Hetzners Infrastruktur. Bei Hetzner wird für jede Domain und jede Subdomain eine Adresse der Form "[domain].www[zahl].your-server.de" eingerichtet. Da wir diese garantiert nicht im Web verlinkt haben wollen, greifen wir uns die tatsächliche Domain aus dieser langen Adresse heraus und leiten auf diese weiter.
  • Der darauf folgende Block kümmert sich um das einer Domain vorangestellte "www.". Diese Subdomain ist eine Abart aus der Frühzeit des Internets, die heutzutage nicht mehr notwendig ist. Deshalb werden Aufrufe der Form "www.[domain]" direkt auf die Domain weitergeleitet.
  • Danach kümmern wir uns um das Setzen des ersten Root-Verzeichnisses (in diesem Fall von der Domain "domain.test"). Dieser wird das Verzeichnis "/domain/" zugewiesen.
  • Danach kümmern wir uns um die Verzeichnisse der beiden Subdomains "subdomaina.domain.test" und "subdomainz.domain.test". Diesen werden die Ordner "/subdomaina/" bzw. "/subdomainz/" zugeweisen.

In freier Wildbahn sieht das dann in etwa so aus: Angenommen, wir wollen das Favicon der Domain example.com aufrufen. Dann können wir das direkt über die Adresse example.com/favicon.ico tun. Intern wird dieser Aufruf jedoch in den Ordner "example" umgeleitet. In Wirklichkeit ruft man also eigentlich die Adresse example.com/example/favicon.ico auf.

Ich bin übrigens enttäuscht, dass Hetzner solch eine Lösung nicht in der Schublade liegen hat, falls ein Kunde mal wirklich ein paar mehr Anforderungen an deren Infrastruktur stellt. Das ist nicht das erste Mal, dass ich der Meinung bin, dass Hetzner sich zu sehr auf der eingerichteten, unzureichenden Infrastruktur ausruht und es wird auch nicht das letzte Mal gewesen sein.

Und an alle Sicherheitsfanatiker unter uns: Es ist egal, dass alle Domains in Wirklichkeit das gleiche Wurzelverzeichnis besitzen. Bei Hetzner ist der safe_mode ausgeschaltet. Selbst wenn man jeder Subdomain ihr eigenes Root-Verzeichnis zuweist, könnten diese also aus ihrem Verzeichnis "ausbrechen".
Subdomain-Grüße, Kenny

P.S.: Ich werde gleich nochmal den Hetzner-Support quälen und fragen, ob man mit dieser Lösung wirklich alle Subdomains mit einem einzelnen SSL-Setup schützen könnte.