fragen stichworte

Mehrere SSL-Domänen auf derselben IP-Adresse und demselben Port?

This is a Canonical Question about Hosting multiple SSL websites on the same IP.

Ich hatte den Eindruck, dass jedes SSL-Zertifikat eine eigene Kombination aus IP-Adresse und Port benötigt. Die Antwort auf eine Frage, die ich zuvor gepostet habe, widerspricht dieser Behauptung.

Mithilfe der Informationen aus dieser Frage konnte ich mehrere SSL-Zertifikate für dieselbe IP-Adresse und für Port 443 verwenden. Ich bin sehr verwirrt, warum dies angesichts der oben genannten Annahme funktioniert und durch andere SSL-Domänen verstärkt wird Eine Website auf demselben Server benötigt eine eigene IP/Port.

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

antworten

Ja, aber es gibt einige Einschränkungen.

Dies wird durch die Angabe des Servernamens erreicht, einer Erweiterung der Transport Layer Security.

Was ist der Servername?

Servername (RFC 6066; veraltet RFC 4366, RFC 3546) ist eine Erweiterung der Transportschicht Sicherheit, mit der der Client dem Server den Namen des Hosts mitteilen kann, den er erreichen möchte.

SNI ist laut 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) für die Verwendung von SNI aushandeln. Dies geschieht im Allgemeinen 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 mit dem Header Host: erreichen möchte. Auf diese Weise kann ein Webserver mit einer einzigen IP-Adresse Inhalte für mehrere Hostnamen bereitstellen, die üblicherweise als namensbasiertes -hosting bezeichnet werden.

Die Alternative besteht darin, für jeden zu bedienenden Webhostnamen eindeutige IP-Adressen zuzuweisen. Dies wurde im Allgemeinen in den frühen Tagen des Webs durchgeführt, bevor allgemein bekannt war, dass die IP-Adressen erschöpft waren und die Erhaltungsmaßnahmen eingeleitet wurden. Dies wird auch für virtuelle SSL-Hosts (ohne SNI) durchgeführt.

Da bei dieser Methode zum Übertragen des Hostnamens bereits eine Verbindung hergestellt werden 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 einrichtet.

SNI löst dieses Problem, indem der Client den Hostnamen als Teil der TLS-Aushandlung überträgt, sodass der Server bereits weiß, welcher virtuelle Host für die Verbindung 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-Header Host: wurde definiert, um zu ermöglichen, dass mehr als ein Webhost von einer einzigen IP-Adresse aus bedient werden kann, da es an IPv4-Adressen mangelt, die bereits Mitte der 1990er Jahre als Problem erkannt wurden. In gemeinsam genutzten Webhosting-Umgebungen können Hunderte von einzigartigen, nicht verwandten Websites auf diese Weise über eine einzige IP-Adresse bereitgestellt werden, wodurch der Adressraum gespart wird.

Shared-Hosting-Umgebungen stellten fest, dass der größte Benutzer des IP-Adressraums darin bestand, dass sichere Websites über eindeutige IP-Adressen verfügen, wodurch SNI als Zwischenziel auf dem Weg zu IPv6 erforderlich ist. Heutzutage ist es manchmal schwierig, nur fünf 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, die Techniken werden jedoch wahrscheinlich noch weit in der Zukunft verwendet alte IPv4-Verbindungen des Dienstes.

Vorsichtsmaßnahmen

Einige Kombinationen von Betriebssystemen und Browsern unterstützen SNI nicht (siehe unten). Daher ist die Verwendung von SNI nicht für alle Situationen geeignet. Sites, die auf solche System-/Browser-Kombinationen 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 nach Angaben von NetMarketShare immer noch einen erheblichen (aber stetig abnehmenden Anteil von rund 16% des Internetverkehrs im Dezember 2012) darstellt, wäre SNI für eine Website ungeeignet, die auf diese Benutzergruppen abzielt.

Unterstützung

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

(Das Auslassen dieser Liste bedeutet nicht notwendigerweise einen Mangel an Unterstützung; es bedeutet, dass die Anzahl der Eingaben begrenzt ist oder ich die Informationen in einer Suche nicht schnell finden konnte. Wenn Ihr Softwarepaket nicht vorhanden ist aufgelistet, suchen Sie nach seinem Namen und sni sollte anzeigen, ob Support vorhanden ist und wie Sie ihn einrichten.)

Bibliotheksunterstützung

Die meisten Pakete benötigen eine externe Bibliothek, 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 Konfigurationsflags
  • Qt 4,8 oder höher

Serverunterstützung

Die meisten aktuellen Versionen gängiger Serversoftware unterstützen SNI. Für die meisten dieser Anwendungen sind Setup-Anweisungen verfügbar:

Kundenunterstützung

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)
  • Safari 3.0 unter Windows Vista/Server 2008 oder höher oder Mac OS X 10.5.6 oder höher

Handy

  • 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 SNI-Unterstützung zurückgeschickt)

Kein Support

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

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

For the most up-to-date information on Apache and SNI, including additional HTTP-Specific RFCs, please refer to the Apache Wiki


FYsI: "Mehrere (verschiedene) SSL-Zertifikate auf einer IP" werden durch den Zauber des TLS-Upgrades für Sie bereitgestellt. Es funktioniert mit neueren Apache-Servern (2.2.x) und einigermaßen aktuellen Browsern (ich kenne keine Versionen von Kopf bis Fuß).

RFC 2817 (ein Upgrade auf TLS innerhalb von HTTP/1.1) hat die blutigen Details, aber im Grunde funktioniert es für viele Leute (wenn nicht die Mehrheit).
Sie können das alte funky-Verhalten mit openssl Befehl (oder ein beliebiger Browser).

Bearbeiten, um hinzuzufügen: anscheinend kann curl Ihnen zeigen, was hier besser passiert als bei 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.

Das Problem:

Wenn ein Webclient und ein Webserver über HTTPS miteinander kommunizieren, ist das allererste -Ding der sichere Handshake.

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

tls handshake

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

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

Dadurch wurden mehrere virtuelle Hosts auf einer einzigen IP-Adresse möglich, da der Server genau weiß, auf welche Domäne der Client zugreifen möchte, nämlich example.com.

HTTPS unterscheidet sich. Wie ich schon gesagt habe, kommt der Handschlag vor allem anderen. Wenn Sie den dritten Schritt des oben abgebildeten Handshakes (Zertifikat) betrachten, muss der Server dem Client ein Zertifikat als Teil des Handshakes vorlegen, hat jedoch keine Ahnung, auf welchen Domänennamen der Client zugreifen möchte. Die einzige Möglichkeit, die der Server hat, ist, jedes Mal dasselbe Zertifikat zu senden, sein Standardzertifikat.

Sie können zwar weiterhin virtuelle Hosts auf Ihrem Webserver einrichten, der Server sendet jedoch immer dasselbe Zertifikat an jeden Client. Wenn Sie versucht haben, die Websites example.com und example.org auf Ihrem Server zu hosten, sendet der Server das Zertifikat immer auf example.com, wenn ein Client eine HTTPS-Verbindung anfordert. Wenn ein Client beispiel.org über eine bestehende HTTPS-Verbindung anfordert, würde dies passieren:

enter image description here

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

Die Lösung:

Der einfachste Weg zur Lösung dieses Problems besteht darin, dass der Client dem Server mitteilt, auf welche Domäne er während des Handshakes zugreifen möchte. Auf diese Weise kann der Server das korrekte Zertifikat bereitstellen.

Genau das tun SNI oder die Anzeige des Servernamens.

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

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 allgemeines Zertifikat angezeigt, das dazu führt, dass der Browser eine Warnung oder einen Fehler anzeigt.

enter image description here

Ich habe hier die Dinge vereinfacht, um nur das Prinzip des Problems und die Lösung zu erklären. Wenn Sie eine technischere Erklärung wünschen, können die Seite wikipedia oder RFC 6066 als gute Ausgangspunkte dienen. Eine aktuelle Liste der Server und Browser, die SNI unterstützen, finden Sie auch in wikipedia

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 des Servernamens (RFC6066) ist erforderlich, damit name-basierte vhosts über HTTPS arbeiten können.

Die Erweiterung ist weitgehend implementiert, und ich habe noch keine Probleme mit der aktuellen Software, aber es besteht die Möglichkeit, dass einige Clients (die diese nicht unterstützen) zu Ihrer Standard-Site geleitet werden, wenn Sie auf SNI angewiesen sind.