Dies ist eine kanonische Frage zum Hosten mehrerer SSL-Websites auf derselben IP.

Ich hatte den Eindruck, dass für jedes SSL-Zertifikat eine eigene eindeutige IP-Adresse / Port-Kombination erforderlich ist. Aber die Antwort auf eine frühere Frage, die ich gestellt habe, widerspricht dieser Behauptung.

Unter Verwendung der Informationen aus dieser Frage konnte ich mehrere SSL-Zertifikate für dieselbe IP-Adresse und für Port 443 erhalten. Ich bin sehr verwirrt darüber, warum dies unter der Annahme funktioniert, dass jede SSL-Domain-Website auf der Website von anderen betrieben wird Der gleiche Server benötigt eine eigene IP / Port.

Ich bin misstrauisch, dass ich etwas falsch gemacht habe. Können auf diese Weise mehrere SSL-Zertifikate verwendet werden?

Aktuelle Informationen zu Apache und SNI, einschließlich zusätzlicher HTTP-spezifischer RFCs, finden Sie im Apache-Wiki

FYsI: "Mehrere (verschiedene) SSL-Zertifikate auf einer IP" wird Ihnen durch die Magie des TLS-Upgrades bereitgestellt. Es funktioniert mit neueren Apache-Servern (2.2.x) und einigermaßen aktuellen Browsern (ich kenne keine verrückten Versionen).

RFC 2817 (Upgrade auf TLS in HTTP / 1.1) enthält die wichtigsten Details, funktioniert jedoch grundsätzlich für viele Benutzer (wenn nicht für die Mehrheit).
Sie können das alte funky Verhalten mit dem s_clientBefehl openssl (oder jedem "alt genug" Browser) reproduzieren .

Bearbeiten zum Hinzufügen: curlkann dir anscheinend besser zeigen, was hier passiert als openssl:

SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

Ja, aber es gibt einige Einschränkungen.

Dies wird durch die Angabe des Servernamens erreicht, eine Erweiterung der Transportschichtsicherheit.

Was ist die Angabe des Servernamens?

Die Angabe des Servernamens ( RFC 6066 ; veralteter RFC 4366 , RFC 3546 ) ist eine Erweiterung der Transport Layer Security , mit der der Client dem Server den Namen des Hosts mitteilen kann, den er zu erreichen versucht.

SNI ist gemäß Spezifikation mit TLS 1.0 und höher kompatibel, die Implementierungen können jedoch variieren (siehe unten). Es kann nicht mit SSL verwendet werden, daher muss eine Verbindung TLS (siehe RFC 4346, Anhang E ) aushandeln, damit SNI verwendet werden kann. Dies geschieht in der Regel automatisch mit unterstützter Software.

Warum wird SNI benötigt?

Bei einer normalen HTTP- Verbindung informiert der Browser den Server über den Hostnamen des Servers, den er über den Host:Header erreichen möchte. Auf diese Weise kann ein Webserver mit einer einzigen IP-Adresse Inhalte für mehrere Hostnamen bereitstellen, was allgemein als namensbasiertes virtuelles Hosting bezeichnet wird .

Die Alternative besteht darin, jedem zu versorgenden Webhostnamen eine eindeutige IP-Adresse zuzuweisen. Dies wurde häufig in den Anfängen des Webs getan, bevor allgemein bekannt war, dass IP-Adressen ausgehen und Maßnahmen zur Beibehaltung ergriffen werden, und wird auch für virtuelle SSL-Hosts (ohne SNI) auf diese Weise durchgeführt.

Da bei dieser Methode zur Übertragung des Hostnamens die Verbindung bereits hergestellt sein muss, funktioniert sie nicht mit SSL / TLS-Verbindungen. Zum Zeitpunkt der Einrichtung der sicheren Verbindung muss der Webserver bereits wissen, welchen Hostnamen er dem Client bereitstellen soll, da der Webserver selbst die sichere Verbindung herstellt.

SNI behebt dieses Problem, indem der Client den Hostnamen im Rahmen der TLS-Aushandlung überträgt, sodass der Server bereits weiß, welcher virtuelle Host für die Bereitstellung der Verbindung verwendet werden soll. Der Server kann dann das Zertifikat und die Konfiguration für den richtigen virtuellen Host verwenden.

Warum nicht unterschiedliche IP-Adressen verwenden?

Der HTTP- Host:Header wurde so definiert, dass aufgrund des Mangels an IPv4-Adressen, der bereits Mitte der neunziger Jahre als Problem erkannt wurde, mehr als ein Webhost von einer einzelnen IP-Adresse aus bedient werden kann. In gemeinsam genutzten Webhosting-Umgebungen können auf diese Weise Hunderte von eindeutigen, nicht verwandten Websites mit einer einzigen IP-Adresse bedient werden, wodurch der Adressraum geschont wird.

Shared-Hosting-Umgebungen stellten dann fest, dass der größte Verbraucher von IP-Adressräumen die Notwendigkeit sicherer Websites mit eindeutigen IP-Adressen war, was SNI als Stop-Gap-Maßnahme auf dem Weg zu IPv6 erforderlich machte. Heutzutage ist es manchmal schwierig, nur 5 IP-Adressen (/ 29) ohne wesentliche Begründung zu erhalten, was häufig zu Verzögerungen bei der Bereitstellung führt.

Mit dem Aufkommen von IPv6 sind solche Adresserhaltungstechniken nicht mehr erforderlich, da einem einzelnen Host mehr IPv6-Adressen zugewiesen werden können, als das gesamte Internet heute enthält, aber die Techniken werden wahrscheinlich in der Zukunft noch weit verbreitet sein, um ältere IPv4-Adressen zu bedienen Verbindungen.

Vorbehalte

Einige Kombinationen aus Betriebssystem und Browser unterstützen SNI nicht (siehe unten). Die Verwendung von SNI ist daher nicht für alle Situationen geeignet. Sites, die auf solche System- / Browserkombinationen abzielen, müssten auf SNI verzichten und weiterhin eindeutige IP-Adressen für jeden virtuellen Host verwenden.

Insbesondere unterstützt keine Version von Internet Explorer unter Windows XP SNI. Da diese Kombination immer noch einen signifikanten (aber stetig abnehmenden; laut NetMarketShare etwa 16% des Internetverkehrs im Dezember 2012) Teil des Internetverkehrs darstellt, wäre SNI für eine Website, die auf diese Nutzergruppen abzielt, ungeeignet.

Unterstützung

Viele, aber nicht alle gängigen Softwarepakete unterstützen SNI.

(Das Weglassen von dieser Liste bedeutet nicht notwendigerweise mangelnde Unterstützung. Es bedeutet, dass die Anzahl der Eingaben begrenzt war oder ich die Informationen bei einer Suche nicht schnell finden konnte. Wenn Ihr Softwarepaket nicht aufgeführt ist, wird gesucht für seinen Namen und snisollte zeigen, ob Unterstützung vorhanden ist und wie man es einrichtet.)

Bibliotheksunterstützung

Die meisten Pakete sind von einer externen Bibliothek abhängig, um SSL / TLS-Unterstützung bereitzustellen.

• GNU TLS
• JSSE (Oracle Java) 7 oder höher, nur als Client
• libcurl 7.18.1 oder höher
• NSS 3.1.1 oder höher
• OpenSSL 0.9.8j oder höher
  • OpenSSL 0.9.8f oder höher mit configure-Flags
• Qt 4.8 oder höher

Server-Unterstützung

Die meisten aktuellen Versionen der gängigen Serversoftware unterstützen SNI. Setup-Anweisungen sind für die meisten von diesen verfügbar:

• Apache 2.2.12 oder höher
• Apache Traffic Server 3.2.0 oder höher
• Cherokee
• HAProxy 1.5 oder höher
• IIS 8.0 oder höher
• lighttpd 1.4.24 oder höher
• LiteSpeed ​​4.1 oder höher
• nginx 0.5.32 oder höher

Kundendienst

Die meisten aktuellen Webbrowser und Befehlszeilen-Benutzeragenten unterstützen SNI.

Desktop

• Chrome 5 oder höher
  • Chrome 6 oder höher unter Windows XP
• Firefox 2 oder höher
• Internet Explorer 7 oder höher unter Windows Vista / Server 2008 oder höher
  • Internet Explorer unter Windows XP unterstützt SNI unabhängig von der IE-Version nicht
• Konqueror 4.7 oder höher
• Opera 8 oder höher (möglicherweise muss TLS 1.1 aktiviert sein, um zu funktionieren)
• Safari 3.0 unter Windows Vista / Server 2008 oder höher oder Mac OS X 10.5.6 oder höher

Handy, Mobiltelefon

• Android Browser auf 3.0 Honeycomb oder höher
• iOS Safari unter iOS 4 oder höher
• Windows Phone 7 oder höher

Befehlszeile

• cURL 7.18.1 oder höher
• wget 1.14 oder höher (Distributionen haben möglicherweise einen Patch für die SNI-Unterstützung zurückportiert)

Keine Unterstützung

• BlackBerry Browser
• Internet Explorer (beliebige Version) unter Windows XP

(Hinweis: Einige Informationen zu dieser Antwort stammen von Wikipedia .)

Das Problem:

Wenn ein Webclient und ein Webserver über HTTPS miteinander kommunizieren, ist das allererste, was passieren muss, der sichere Handshake.

Hier ist ein vereinfachtes Beispiel für einen solchen Handshake:

Wenn dies HTTP und nicht HTTPS wäre, hätte der Client als erstes Folgendes gesendet:

GET /index.html HTTP/1.1
Host: example.com

Dies ermöglichte mehrere virtuelle Hosts auf einer einzigen IP-Adresse, da der Server genau weiß, auf welche Domain der Client zugreifen möchte, nämlich example.com.

HTTPS ist anders. Wie ich vorher sagte, kommt der Händedruck vor allem anderen. Wenn Sie sich den dritten Schritt des oben abgebildeten Handshakes ansehen (Zertifikat), muss der Server dem Client ein Zertifikat als Teil des Handshakes vorlegen, hat jedoch keine Ahnung, auf welchen Domainnamen der Client zugreifen möchte. Der Server hat nur die Möglichkeit, jedes Mal dasselbe Zertifikat zu senden, das Standardzertifikat.

Sie können weiterhin virtuelle Hosts auf Ihrem Webserver einrichten, der Server sendet jedoch immer das gleiche Zertifikat an jeden Client. Wenn Sie versuchen, die Websites example.com und example.org auf Ihrem Server zu hosten, sendet der Server immer das Zertifikat für example.com, wenn ein Client eine HTTPS-Verbindung anfordert. Wenn ein Client example.org über eine hergestellte HTTPS-Verbindung anfordert, passiert Folgendes:

Durch dieses Problem wird die Anzahl der Domänen, die Sie über HTTPS bedienen können, effektiv auf eine pro IP-Adresse begrenzt.

Die Lösung:

Der einfachste Weg , dieses Problem zu lösen , ist für den Client , den Server zu sagen , welche Domain es zugreifen möchte während des Handshakes . Auf diese Weise kann der Server das richtige Zertifikat bereitstellen.

Dies ist genau das , was SNI oder Server Name Indication macht.

Mit SNI sendet der Client den Servernamen, auf den er zugreifen möchte, als Teil der ersten Nachricht, dem "Client Hello" -Schritt im obigen Handshake-Diagramm.

Einige ältere Webbrowser unterstützen SNI nicht. Unter Windows XP gibt es beispielsweise keine einzige Version von Internet Explorer , die SNI unterstützt. Beim Zugriff auf eine Ressource über HTTPS auf einem Server, der virtuelle SNI-Hosts verwendet, wird ein generisches Zertifikat angezeigt, das möglicherweise dazu führt, dass der Browser eine Warnung oder einen Fehler anzeigt.

Ich habe die Dinge hier vereinfacht, um nur das Prinzip des Problems und die Lösung zu erläutern. Wenn Sie eine technische Erklärung wünschen , kann die Wikipedia- Seite oder RFC 6066 als guter Ausgangspunkt dienen. Auf Wikipedia finden Sie auch eine aktuelle Liste der Server und Browser, die SNI unterstützen

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Der Client-Browser muss auch SNI unterstützen. Hier sind einige Browser, die dies tun:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

Die TLS-Erweiterung mit Angabe des Servernamens (RFC6066) ist erforderlich, damit namenbasierte vhosts über HTTPS funktionieren.

Die Erweiterung ist weit verbreitet und ich habe noch keine Probleme mit der aktuellen Software, aber es besteht die Möglichkeit, dass einige Clients (die sie nicht unterstützen) auf Ihre Standardwebsite weitergeleitet werden, wenn Sie von SNI abhängig sind.