Mit Apache 2.2.12 und Unterstützung für die SNI-Erweiterung zum SSL-Protokoll lassen sich namenbasierte HTTPS-Sites ebenso wie HTTP-Sites konfigurieren. ZDNet stellt die Apache-Funktion vor und zeigt, wie man sie einrichtet.
Der Apache-Webserver wächst und reift, neue Funktionen kommen hinzu und alte Fehler werden behoben. Wahrscheinlich ist eine der wichtigsten hinzugekommenen Funktionen bei Apache-Versionen 2.2.12 die lang erwartete Unterstützung für mehrere SSL-Sites unter einer einzigen IP-Adresse.
Früher konnte man nur eine SSL-fähige Website haben, wenn sie an eine bestimmte IP-Adresse gebunden war. Dies hat eine Menge Probleme und Frust verursacht, denn wer nur zwei IP-Adressen hatte, konnte auch nur zwei SSL-fähige Websites haben.
Unter zwei IP-Adressen kann man eine beliebige Zahl von regulären HTTP-Sites führen, die entweder an beide oder an nur eine IP-Adresse gebunden sind, doch für jede Adresse gibt es nur eine HTTPS-Site. Noch schlimmer ist es, wenn www.beispiel1.com und www.beispiel2.com dieselbe IP-Adresse haben und beispiel1.com auch über eine HTTPS-Site verfügt, da dann der Besuch von https://www.beispiel2.com/ auf das Gleiche hinausläuft wie der Besuch von https://www.beispiel1.com/. Das führt dazu, dass die meisten, die HTTPS-Sites haben wollen, eine Site (sowohl die HTTP- wie auch die HTTPS-Variante) auf eine einzige IP-Adresse beschränken müssen, um derartige Probleme zu vermeiden.
Mit Apache 2.2.12 und der Unterstützung für die SNI-Erweiterung (Server Name Indication) für das SSL-Protokoll hat sich das komplett geändert. Jetzt kann man namenbasierte HTTPS-Sites konfigurieren, ebenso wie man namenbasierte HTTP-Sites konfigurieren kann. Der Vorteil ist, dass statt der fünf IP-Adressen, die man benötigte, um fünf SSL-Sites zu betreiben, künftig nur noch eine einzige erforderlich ist.
Es müssen jedoch einige Anforderungen erfüllt sein:
- Der Server muss mit Apache 2.2.12 oder höher arbeiten.
- Er muss außerdem OpenSSL 0.9.8f oder später verwenden und über die TLS-Erweiterungsoption verfügen.
- Apache muss für diese Version von OpenSSL konzipiert sein, da es die SNI-Unterstützung aktiviert, wenn es die richtige Version von OpenSSL erkennt - die Version von OpenSSL, die die Unterstützung für die TLS-Erweiterung enthält.
Praktisch bedeutet dies, dass die Sache für eine ernsthafte E-Commerce-Website oder für eine Website mit großem Publikum (noch) nicht funktioniert. Aber in den nächsten Jahren dürften viele Leute aufrüsten und somit werden noch mehr Browser SNI unterstützen.
Für Testzwecke oder für interne Sites, bei denen man ein Wörtchen bei der Installation von Client-Browsern mitreden darf, kann die Nutzung von SNI ganz praktisch sein.
Hier ein Beispiel, was bei der Konfiguration in der Apache-Konfigurationsdatei stehen muss:
Damit bringt man Apache dazu, auf Port 443 zu hören und schaltet das Horchen auf Anfragen an einen virtuellen Host bei allen IPs ein. Das neue Schlüsselwort SSLStrictSNIVHostCheck ist deaktiviert, was bedeutet, dass kein Fehler 403 ausgegeben wird, wenn der Client SNI nicht unterstützt. Stattdessen wird er zu der SSL-Site umgeleitet, die zuerst definiert wurde (beispiel1.com im Beispiel), man muss also darauf achten, dass zuerst die Default-Site definiert wird.
Das war schon so ziemlich alles. Die größte Hürde ist hier die Unterstützung durch die Clientbrowser, doch wird sich das mit der Zeit geben. Anforderungen und Konfiguration von Apache sind dagegen sehr einfach und unkompliziert.