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.

4 Kommentare » Schreibe einen Kommentar

  1. Guten Abend Kenny

    Per Google bin ich auf Deine Infos gestossen. Wir haben einen manged Server MX90. Einwenig "gewöhnungsbedürftig" war die KonsoleH schon... aber nun seis drum. Wir wollen nun ALLE Subdomains auf den Root umleiten und dann das Handling unserer App überlassen. Also auch solche, diese NICHT gibt.

    Mein .htaccess:

    1
    2
    3
    4
    5
    RewriteEngine on
    RewriteBase /

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

    Aber da passiert nix mit den Subdomains. Wennman mit WWW die Domain aufruft, geht das wunderbar nach "ohne WWW", aber die Subdomains gehen auf diese komische Hetzner Loginseite für Webmail und Konfiguration.

    Kann man das umgehen?

    Danke schon mal für Deine Info.

    • Hallo Markus, damit das alles so funktioniert, wie es soll, müssen natürlich auch die Subdomains im DNS auf euren Server zeigen. Da jedoch alle anderen Subdomains zum Hetzner-Webmail weiterleiten, klingt es, als ob die Subdomains auch genau dorthin zeigen. Die Weiterleitung von WWW funktioniert deshalb, weil für diese spezielle Subdomain typischerweise eine Extra-Regel definiert ist.

      Wenn ich mich recht entsinne, gab es in der KonsoleH eine DNS-Verwaltung, in der man auch explizit eine Quelltext-Bearbeitung wählen konnte. Dort müsste man dann entsprechend einen Eintrag wie diesen hier platzieren:

      1
      * IN A <eure IP-Adresse>
  2. Hallo Kenny,

    vielen Dank für den Artikel. Bin leider erst jetzt darauf gestoßen (nachdem ich endlose Mailwechsel mit dem Hetzner Support zu diesem Thema geführt habe). Hast du bereits weitere Erfahrungen mit dieser Konfiguration sammeln können?

    Viele Grüße ...

    • Hallo! Ich habe meine Webseiten ca. 1 Jahr auf diese Weise betrieben. Natürlich habe ich dabei auch ein paar Erfahrungen gesammelt.

      Prinzipiell funktioniert das ganze, allerdings muss die Software damit umgehen können, das sie nicht im DocumentRoot liegt, aber so aufgerufen wird, als wäre sie es. Größere Software, wie zum Beispiel WordPress, hat damit selten ein Problem - dort wird es mitunter sogar (geringen) Steigerung der Sicherheit genutzt.

      Bei kleinerer und selbstgeschriebener Software sieht das aber vielleicht anders aus. Diese geht mitunter davon aus, dass sie im DocumentRoot liegt und generiert potentiell fehlerhafte URLs, wenn dem nicht so ist. Andere Fehlerfälle können sein, dass die Software prüft, ob eine URL eine bestimmte Struktur hat und redirected, wenn dem nicht so ist - im schlechtesten Fall entsteht so eine endlose Redirect-Kette in den Unterordner und zurück.

      Einer Stelle krankt die gezeigte Lösung zudem besonders: Da man praktisch nur ein TLS-Zertifikat verwendet, müssen alle Domains, die man betreibt in diesem einen Zertifikat enthalten sein. Das geht zwar - per SubjectAltNames - ist aber bei typischen CAs ziemlich teuer. Alternativ muss man auf CAcert oder selbstsignierte Zertifikate zurückgreifen.

      Ich persönlich würde inzwischen vom Webhosting-Angebot von Hetzner gänzlich abraten. Bei Rootservern sind sie wirklich toll - ich habe dort selbst mehrere angemietet. Beim Webhosting macht jedoch uberspace.de seine Sache einfach wesentlich besser. Dort kann man für jede Domain, die man auf seinen Uberspace schaltet, ein Zertifikat verknüpfen. Kostenlos. No Strings attached. Die kann man sich z.B. kostenlos bei StartSSL ausstellen lassen - ohne SubjectAltNames oder anders Geraffel, mit dem man sich sonst rumschlagen muss.

      I hope it helps. 🙂

      P.S.: Eine Sache ist mir noch eingefallen. Man muss sich bewusst sein, dass bei dieser Lösung alle Webseiten unter dem gleichen User ausgeführt werden und somit der Quellcode jeder Webseite Zugriff auf alle anderen Webseiten hat. Sprich: Wird in einer dieser Webseiten eine Lücke gefunden und ausgenutzt, gelten automatisch auch alle anderen Webseiten als angegriffen. Das war schlussendlich auch einer der Gründe, warum ich meine Webseiten heute nicht mehr auf diese Art betreibe (der andere Grund war das Fehlen einer ordentlichen Backup-Strategie).

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.