Ein Rechner, mehrere Domains und dann auch noch Zertifikate!

Es ist teilweise unglaublich, wieviele Probleme man bekommen kann, wenn man einen eigenen Server betreiben will. Das fängt bei der Erreichbarkeit an (Stichwort dynamische IP), geht über die Probleme beim E-Mail-Versenden (Stichwort Reverse-DNS) und endet bei den SSL-Zertifikaten.

Die Zertifikate haben es nämlich ganz schön in sich. Aber fangen wir vorne an: Wenn ein Rechner sich mit einem Server über den Domainnamen verbindet, dann funktioniert das, indem der Rechner bei einem DNS-Server anfragt, wie denn die IP des Rechners ist, der sich hinter dem Namen versteckt. Der Rechner verbindet sich dann mit der IP und beginnt mit der eigentlichen Kommunikation.
Wenn der Rechner also bei dem Server aufschlägt, hat der Server garkeine Ahnung, dass der Besucher mit einer bestimmten Domain sprechen möchte. Diese Information wird z.B. einem HTTP-Server erst im weiteren Gesprächsverlauf mitgeteilt.

Jetzt kommt aber das große Problem: Wenn ein Rechner sich mit dem Server verbindet und der Rechner eine verschlüsselte SSL-Verbindung haben möchte, dann muss der Server ein passendes Zertifikat zurückliefern. In diesem Zertifikat steht der Domainname, für den das Zertifikat gilt.
Der Stolperstein ist nun, dass der Server das passende Zertifikat zurückgeben muss, obwohl ihm der Rechner noch garnicht verraten hat, welche Domain er überhaupt abrufen will!

Um dieses Problem zu lösen gibt es nun mehrere Möglichkeiten, von denen ich mir einige angeguckt habe und die ich mal ein bisschen näher erklären will.

Fangen wir mal mit der Lösung an, die wohl die wenigstens Haushalte "einfach so" aus dem Stehgreif lösen können: Dem Rechner mehrere IPs zuweisen. Hintergrund ist, dass einer Netzwerkkarte mehrere IPs zugewiesen werden können. Anhand der IP, an die die Abfrage gerichtet ist, kann der Server nun herausfinden, welche Domain erfragt werden soll. Je nachdem wird dann einfach das passende Zertifikat verteilt.
Die Lösung ist für den Privathaushalt deshalb unpraktikabel, da man als Privatperson von seinem Internetanbieter meist nur eine einzige IP zugewiesen bekommt. Es gibt zwar die Möglichkeit, sich z.B. bei Manitu mehrere IPs zu besorgen, jedoch bekommt man dann das Problem, dass man einen professionellen Router benötigt, der in der Lage ist, mehrere öffentliche IPs zu verwalten.

Deshalb habe ich lange daran gedacht, folgende Lösung umzusetzen: Ich besorge mir eine Domain, über die sämtliche verschlüsselte Kommunikation abläuft. Wenn jemand SSL benutzen möchte und keine Programmwarnungen sehen will, soll er halt über diese designierte Domain gehen, da diese dann in den Zertifikaten steht. Das einzige Problem wäre, dass ein Benutzer sich evtl. wundert, dass er von einer Webseite auf eine komplett andere Domain weitergeleitet wird. Alles andere könnte man durch korrekte Konfiguration und durch Programmierung lösen.

Für viele würde diese Variante sicherlich ausreichen - ich persönlich finde sie allerdings ziemlich unschön. Also habe ich weitergesucht und habe die TLS-Erweiterung namens SNI gefunden. Diese löst genau das oben Problem: Bei der Verwendung von SNI wird bereits beim Aufbau der verschlüsselten Verbindung mitgeteilt, welche Domain angesprochen werden soll. Dadurch kann der Server das passende Zertifikat heraussuchen und die Verbindung korrekt herstellen. An sich eine gute Lösung...

...wenn denn der Server es nicht explizit unterstützen müsste. Leider gibt es immernoch einige Serversoftware, die ausschließlich SSL (bzw. TLS 1.0) unterstützen. Deshalb habe ich noch weiter gesucht und bin schlussendlich beim X.509-Standard gelandet. Dieser beschreibt, welche Werte in einem Zertifikat stehen. Auch dieser hat in letzter Zeit eine Veränderung erfahren, die für unsere Belange genutzt werden kann: Gemeint ist die Erweiterung SubjectAltName.
Diese sieht vor, dass man ein Zertifikat erstellen kann, das für mehrere Domains gültig ist - nämlich genau für die, die im Feld SubjectAltName hinterlegt sind.
Der Vorteil ist, dass dieses Vorgehen mit allen Servern funktioniert - auch, wenn sie die Erweiterung nicht unterstützen. Lediglich der Client muss sie auswerten können. Sollte es nun einen Client geben, der lediglich den Common Name (CN) auswertet, so kann man für diesen zumindest noch zusätzlich die oben erwähnte Variante mit der separaten SSL-Domain anbieten.

Abschließend wollte ich euch noch zeigen, wie man relativ einfach ein selbst-signiertes Zertifikat mit integrierten SubjectAltNames erstellen kann. Basis hierfür waren die Artikel auf therowes.net, iiegn.blogspot.com und sial.org.

Wenn man es noch nicht hat, muss man sich zuerst einmal einen privaten Schlüssel erzeugen. Das geht bei OpenSSL mit diesem Befehl:

1
openssl genrsa 2048 > key.rsa

Denkt bitte dran, dass dies der private Schlüssel ist, der im Moment nicht mit einem Passwort geschützt ist. Einige Serverprogramme brauchen ihn in diesem Zustand. Der Schlüssel muss in diesem Zustand unbedingt vor unbefugtem Zugriff geschützt werden!

Als nächstes muss die Datei "openssl.cfg" der OpenSSL-Installation bearbeitet werden. Über den interaktiven Modus von OpenSSL ist es derzeit nicht möglich, die SubjectAltNames zu definieren, deshalb muss dies in der Konfigurationsdatei geschehen.

Guckt zuerst, ob im Bereich "req" der Wert "req_extensions" auf "v3_req" gesetzt ist:

1
2
[ req ]
req_extensions = v3_req # The extensions to add to a certificate request

Als nächtes müsst ihr in den Bereichen "v3_req" und "v3_ca" den Wert "subjectAltName" auf "@subject_alt_names" setzen:

1
2
[ v3_req ]
subjectAltName=@subject_alt_names
1
2
[ v3_ca ]
subjectAltName=@subject_alt_names

Abschließend müsst ihr einen neuen Bereich "subject_alt_names" anlegen und dort die Domains reinschreiben, für die das Zertifikat gelten soll. Vergesst hier auf keinen Fall die Domain, die im Common Name stehen wird!

1
2
3
4
5
[ subject_alt_names ]
DNS.1 = example.com
DNS.2 = *.example.com
DNS.3 = example.net
DNS.4 = *.example.net

Und nun liegt es an euch, auf welchem Weg ihr das Zertifikat erstellen wollt. Wenn ihr über einen CSR gehen wollt, wird die Einstellung im Bereich "v3_req" verwendet. Wenn ihr jedoch gleich selbst signiert, sind die Einstellung in "v3_ca" aktiv.

Ich persönlich habe den zweiten Weg genommen, da ich mir damit das Erstellen einer eigenen CA gespart habe. Der Befehl für den direkten Weg lautet wie folgt:

1
openssl req -new -x509 -nodes -sha1 -days 365 -key key.rsa > key.rsa.cert

Beim Ausführen des Befehls werdet ihr nach den Werten für das Zertifikat gefragt. Vergesst nicht, den Common Name richtig zu setzen. Das dabei herauskommende Zertifikat wird 365 Tage lang gültig sein. Dieses Zertifikat muss übrigens nicht (im Gegensatz zum privaten Schlüssel) gesondert gesichert werden - es wird sowieso vom Server an jeden geschickt, der danach fragt! 😀

Sooo... meine Güte! Der Artikel ist länger geworden, als ich gedacht hatte 😀 ! Ich muss aber auch zugeben, dass ich ihn eine ganz schöne Zeit vor mir hergeschoben habe und er zeitweise zu einer reinen internen Referenzsammlung verkommen war 😉 . Der Artikel ist auch für mich wichtig, damit ich nicht vergesse, welchen Weg ich nun schlussendlich gegangen bin 😀 !

Wie hat auch der Artikel gefallen? Standet/steht ihr auch von dem Problem? Wie habt ihr es gelöst? Wäre der gezeigte Weg eine Lösung, die ihr in Betracht ziehen würdet?
Verschlüsselnde Grüße, Kenny

13 Kommentare » Schreibe einen Kommentar

  1. Hi Kevin ich wollte dir eine Mail senden an die in deinen Impressum angegebe Mailadresse, kamm folgendes zurück

    This message was created automatically by mail delivery software.

    A message that you sent could not be delivered to one or more of its
    recipients. This is a permanent error. The following address(es) failed:

    ??

    • Echt? Das ist ja unschön 🙁 . Wer weiß, was die schon wieder an dem Server rumschrauben 🙁 . Habe mir jetzt mal testhalber selber eine Mail geschickt und werde jetzt gucken, ob die ankommt.

  2. Ok bei 8 Domains geht noch, wie aber gesagt kommt immer darauf an was du machen willst mit der Webseite und eben was für Anwendungen notwendig sind, zb bei einen Gameserver würde ich evt auch eigenen Server nehmen.

    Aber so habe Anbieter 25 Gb Speicher + Datenbanken 20 und Wunscheinstellung inlk 10 Domains DE 47,80€ im Jahr das macht allein zu deinen Anbieter weil ähnlich 8 Domain SelfHost.de ( also nicht ganz korekt ausgerechnet, ich gebe dir noch zwei Domais dazu um die rechnung zu vereinfachen )ist das schon ein plus für mich von 117,20€

    bei 100 Domains wären das bei dir Kosten von 1650€
    bei 100 Domains bei mir 478€
    Differenz; 1172€
    Ohne das ich weitere Kosten habe, Datensicherung ist vorhanden, gern kann man ja aber seine Daten selber sichern

    • 47,80€ pro Jahr für 25GB HDD und 10 Domains? Was für ein Anbieter ist das denn? Was für Hardware (CPU und RAM) steht dahinter? Meiner Meinung nach ist dieses Angebot ziiieeemlich günstig! 😀

  3. ja das DE Domains schreibe ich vorher auch schon 🙂 com, etc sind % teuerer ist klar, wird bei dir aber auch so sein wenn zb eine asia Domain gebucht wird.
    Und ok das mag bei der Buchung von 2 bis 3 Domains kein Thema sein, die 20 bis 30€ mehr, wenn man aber zb 100 Domain hat dann rechnet sich das anders

    Ist aber auch alles eine Sache wie man es selber gern macht, hat alles Vor und Nachteile, ein eigener Server wo ich auch noch alles technische machen müsste wäre mir zu stressig, wenn es auch manchen Vorteil haben kann.

    • Ich habe derzeit unter 10 Domains, da lohnt es sich durchaus noch. Aber du hast Recht: Je mehr Domains, umso unwirtschaftlicher wird das dynamische Domain-Hosting. Aber wir können ja mal nachrechnen (bitte berücksichtigen, dass der eigene Internetanschluss außen vor gelassen wird, da ich den auch dann hätte, wenn ich keinen Server hosten würde).

      Pro Domain bezahle ich bei SelfHost.de derzeit 18€ (nicht mit eingerechnet sind die 5% Rabatt, die ich inzwischen erhalte). Bei 8 Domains macht das Kosten in Höhe von 144€. Dazu kommen Stromkosten in Höhe von 20€. Als Server nutze ich derzeit ein altes IBM Thinkpad T23 mit 1GB Ram, 1.2GHz CPU und 35GB HDD. Macht für den Serverbetrieb also rund 165€ jährlich inklusive der Domains für das Self-Hosting.

      Bisher habe ich alles bei einem Shared Hoster hinterlegt gehabt. Für WeizenSpr.eu bezahle ich im Moment 40€ pro Jahr. Da die anderen Domains weniger Anforderungen haben, kosten diese mich im Schnitt 25€ im Jahr (einige ein bisschen mehr, aber das lasse ich jetzt mal unter den Tisch fallen). Dazu kommen pro Jahr pro Domain 5€, die ich investiere, damit mein Hoster für mich regelmäßig eine Datensicherung vornimmt. Damit komme ich beim Shared Hosting auf 40€+(7*25€)+(8*5€)=255€ pro Jahr. Man sieht, das Shared Hosting ist relativ teuer und hat den Nachteil, dass man selbst nicht bestimmen kann, welche Software man zur Verfügung hat oder wieviel Leistung einem zur Verfügung steht.

      Da ich nur ungern auf Linux hosten will, habe ich jetzt mal nach einem VServer mit Windows gesucht. Ich weiß, ich betreibe zuhause einen Dedicated Server, allerdings sind diese im Web meist viel besser ausgerüstet als mein T23 und dadurch wesentlich teurer. Bei United Hoster bin ich auf ein relativ günstiges Angebot gestoßen (ab 7,90€ pro Monat). Damit ich jedoch die Leistung habe, die mir mein T23 bietet, müsste ich auf das teuerste Produkt "VPS Business" ausweichen, das schon mit 19,90€ pro Monat zu Buche schlägt. Dazu kommen 7,90€ für DE-Domains, 9,90€ für COM-, NAME- und NET-Domains, sowie 12€ für EU-Domains. Damit komme ich bei diesem Paket auf (12*19,90€)+12€+(2*7,90)+(5*9,90€)=316,10€ pro Jahr.

      Mit den 150€ Differenz kann ich beim Self-Hosting neue Hardware abbezahlen oder bestehende Hardware aufrüsten.

  4. Ja klar, aber ich denke deine Kosten für Domain sind höher, bei united zb de Domain 12,50€ bei einen gemieteten Server je nach dem wo zwischen 1,00€ bis 8€ und wieviel bezahlst du?

    • Im Moment sind es 18€ pro Domain pro Jahr. Durch eine statische IP könnte ich das ganze auf 12€ pro Domain pro Jahr drücken.

      Nebenbei denke ich nicht, dass United Domains damit vergleichbar ist. Ein Komilitone hatte damals via United Domains einen selbstgehosteten Server erreichbar gemacht - eher schlecht als recht: Eine ordentliche DNS-Auflösung schien nicht möglich zu sein.
      (Und ganz unter uns: Um einen Registrar, der *.de.com und *.eu.com Domains anbietet, sollte man einen groooßen Bogen machen.)

      Zwischen 1€ bis 8€ pro Domain? Das sind dann aber *.de-Domains, oder? *.eu, *.net, *.com und *.name kriegt man afaik nicht so günstig.

  5. Also ein eigener Server wäre mir zu stressig und zu teuer, weil die Kosten die du nachher für die Domain hast musst du ja auch noch hinzurechnen

  6. Und warum hast du dir nun keinen Server angemietet? Damit du diesen ganzen Kram zweck Dyn-IP umgehen kannst.

    Dann wäre nämlich der ganze SSL-Quatsch auch einfacher geworden. Denn soweit ich es in Erinnerung habe, muss ja SNI auch vom Clienten unterstützt werden, was zwar alle modernen Browser offensichtlich tun, aber mensch weiß ja nie ...

    Und bei subjectAltName bin ich mir auch nicht sicher, ob das alles so reibungslos funktioniert, gehört habe ich bis eben jedenfalls noch nix davon. Aber man lernt ja immer dazu.

    • Ich habe deshalb keinen Server angemietet, weil ich den Server unter meiner (physischen) Kontrolle haben möchte. Dabei geht es u.a. um die Datenhaltung (per RAID-1 NAS), die Netzarchitektur, etc.
      Wenn irgendwas sein sollte, kann ich direkt an den Rechner ran und muss niemanden beauftragen oder gar in ein Rechenzentrum fahren. Abgesehen davon geht es mir um das Preis-/Leistungsverhältnis - Self-Hosting ist meiner Meinung nach in der Beziehung unschlagbar.

      Der "SSL-Quatsch" wäre durch einen angemieteten Server übrigens nicht einfacher geworden. Denn auch dort bekommst du im Regelfall nur eine IP und bist dadurch in der gleichen Situation wie Zuhause.

      Ja, du hast Recht, dass SNI auch vom Client unterstützt werden muss - genauso wie bei den SubjectAltNames. Die SubjectAltNames haben jedoch den Vorteil, dass sie dem Server egal sind. Dadurch hat man weniger Probleme beim Ausrollen.

      Zu den SubjectAltNames: Laut RFC 2818 Kapitel 3.1. ("Server Identity") ist dieser der empfohlene Weg, um anzugeben, für welche Identität (aka. Domainname) das Zertifikat gültig ist.
      "If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."

      Und wie Tests gezeigt haben, werden die SubjectAltNames bereits ziemlich gut unterstützt.

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.