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


Das ist ein Kanonische Frage über Hosting mehrerer SSL-Websites auf derselben IP-Adresse.

Ich hatte den Eindruck, dass jedes SSL-Zertifikat eine eigene eindeutige IP-Adresse / Port-Kombination voraussetzt. Aber die antworte auf eine vorherige Frage, die ich gestellt habe steht im Widerspruch zu dieser Behauptung.

Anhand der Informationen aus dieser Frage konnte ich mehrere SSL-Zertifikate für die gleiche IP-Adresse und Port 443 erstellen. Ich bin sehr verwirrt, warum dies angesichts der obigen Annahme und der Verstärkung durch andere der Fall ist Der gleiche Server benötigt eine eigene IP / Port.

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


107
2018-02-04 22:36


Ursprung


Dieser Q-Körper sagt mehrere Zertifikate und die Antworten sind dafür richtig. Aber der Titel sagt mehrere Domains und Sie kann mehrere Domains mit einem Zertifikat haben (und kein SNI), siehe serverfault.com/questions/126072/... und serverfault.com/questions/279722/... kreuzen Sie auch auf security.SX. - dave_thompson_085


Antworten:


Die aktuellsten Informationen zu Apache und SNI, einschließlich zusätzlicher HTTP-spezifischer RFCs, finden Sie in der Apache Wiki


FYsI: "Mehrere (verschiedene) SSL-Zertifikate auf einer IP" werden Ihnen durch die Magie von TLS Upgrade gebracht. Es funktioniert mit neueren Apache-Servern (2.2.x) und einigermaßen aktuellen Browsern (Versionen nicht von oben bekannt).

RFC 2817 (Upgrade auf TLS in 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 reproduzieren s_client Befehl (oder irgendein "alt genug" Browser) obwohl.

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

68
2018-02-04 23:46



Das ist sehr nützlich - Danke! Gibt es Informationen darüber, wie Sie Apache für TLS anstelle von SSL konfigurieren? - Josh
Ich denke, dass Apache 2.2 nur die TLS-Bits in seiner Chiffre-Liste aktiviert haben muss. Ich gebe zu, dass ich das ganze "Upgrade von SSL zu TLS" -Bit bis zu diesen beiden Seiten noch nie in Aktion gesehen habe. Mein Verständnis der TLS-Dokumente ist, dass es eine zulässige (aber ungewöhnliche) Situation ist, diese Art von Upgrade zu verhandeln ... - voretaq7
Dies ist das erste Mal, dass ich es auch noch gesehen habe und ich versuche immer noch, meine Kiefer vom Boden zu ziehen ... - Josh
OK, meine Antwort hat sich nur verdreifacht - Anscheinend kann curl sowohl SSLv3 als auch TLSv1 Verhandlungen führen, so dass ich den Fehler und den Erfolg zeigen kann. Ich wünschte, ich hätte einen Protokoll-Debugger, um den magischen Teil zu zeigen. (Auch getestet und glücklich zu berichten, dass der Server von johnlai2004 SSLv2-Verbindungen korrekt verweigert :-) - voretaq7
Das ist sehr hilfreich und ich hoffe, dass Johnlai2004 Ihre Antwort akzeptiert. Danke vielmals! - Josh


Ja, aber es gibt einige Vorbehalte.

Dies wird durch Server Name Indication erreicht, eine Erweiterung für Transport Layer Security.

Was ist die Angabe des Servernamens?

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

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

Warum wird SNI benötigt?

In einer normalen HTTP Verbindung, informiert der Browser den Server über den Hostnamen des Servers, den er zu erreichen versucht Host: Header. Dies ermöglicht es einem Webserver unter einer einzigen IP-Adresse, Inhalte für mehrere Hostnamen bereitzustellen, was allgemein als bekannt ist Namensbasiertes virtuelles Hosting.

Die Alternative besteht darin, eindeutige IP-Adressen für jeden Web-Host-Namen zuzuweisen, der bedient werden soll. Dies wurde üblicherweise in den frühen Tagen des Internets getan, bevor allgemein bekannt war, dass die IP-Adressen auslaufen würden und Erhaltungsmaßnahmen begannen, und dies auch weiterhin für SSL-virtuelle Hosts (ohne SNI) getan wird.

Da diese Methode zur Übertragung des Hostnamens erfordert, dass die Verbindung bereits hergestellt wurde, funktioniert sie nicht mit SSL / TLS-Verbindungen. Wenn die sichere Verbindung eingerichtet ist, 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 zum Warten der Verbindung verwendet werden sollte. Der Server kann dann das Zertifikat und die Konfiguration für den korrekten virtuellen Host verwenden.

Warum nicht verschiedene IP-Adressen verwenden?

Das HTTP Host: Header wurde definiert, um mehr als einen Web-Host von einer einzigen IP-Adresse aufgrund der Knappheit von IPv4-Adressen zu bedienen, die bereits Mitte der 1990er Jahre als Problem erkannt wurden. In geteilten Webhosting-Umgebungen können Hunderte einzigartiger, nicht miteinander verwandter Websites unter Verwendung einer einzigen IP-Adresse auf diese Weise bedient werden, wodurch der Adressraum gespart wird.

Shared-Hosting-Umgebungen stellten dann fest, dass der größte Verbraucher von IP-Adressraum die Notwendigkeit war, dass sichere Websites eindeutige IP-Adressen haben mussten. Dies führte dazu, dass SNI als Stop-Gap-Maßnahme auf dem Weg zu IPv6 benötigt wurde. 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 Techniken zur Adresserhaltung nicht mehr notwendig, da einem einzelnen Host mehr IPv6-Adressen zugewiesen werden können, als das gesamte Internet heute enthält, aber die Techniken werden wahrscheinlich noch weit in der Zukunft verwendet werden, um Legacy-IPv4 zu bedienen Verbindungen.

Vorbehalte

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

Besonders hervorzuheben ist, dass keine Version von Internet Explorer unter Windows XP SNI unterstützt. Da diese Kombination immer noch einen bedeutenden (aber stetig abnehmenden; ca. 16% des Internetverkehrs im Dezember 2012 nach NetMarketShare) Teil des Internetverkehrs darstellt, wäre SNI für eine Website, die diese Nutzergruppen anspricht, nicht geeignet.

Unterstützung

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

(Auslassung von dieser Liste bedeutet nicht notwendigerweise Mangel an Unterstützung; es bedeutet, dass es eine Grenze gab, wie viel ich tippen konnte, oder ich konnte die Informationen in einer Suche nicht schnell finden. Wenn Ihr Softwarepaket nicht aufgelistet ist, suchen für seinen Namen plus sni sollte zeigen, ob es Unterstützung gibt und wie sie eingerichtet wird.)

Bibliotheksunterstützung

Die meisten Pakete sind auf eine externe Bibliothek angewiesen, um SSL / TLS-Unterstützung bereitzustellen.

  • GNU TLS
  • JSSE (Oracle Java) 7 oder höher, nur als Kunde
  • 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 der gängigen Server-Software unterstützen SNI. Für die meisten sind Setup-Anweisungen verfügbar:

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, läuft 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, Mobiltelefon

  • Android Browser auf 3.0 Honeycomb oder höher
  • iOS Safari auf 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 a patch für SNI-Unterstützung)

Keine Unterstützung

  • BlackBerry-Browser
  • Internet Explorer (jede Version) unter Windows XP

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


96
2017-08-14 23:05



Viel besser :-) Hoffentlich wird dies eventuell eine höhere Punktzahl erreichen als die aktuell angenommene, die abgesehen von der letzten Bearbeitung an der Spitze, leider meistens falsch ist. - Bruno
@Bruno Ich werde mich sicherlich nicht beschweren, wenn Sie ein paar hundert Leute finden, um es zu verbessern. :) - Michael Hampton♦
Der neueste BlackBerry Browser (10?) Verwendet eine aktuelle Version von WebKit, daher ist es sehr wahrscheinlich, dass er jetzt SNI unterstützt. - dave1010


Das Problem:

Wenn ein Webclient und ein Webserver über HTTPS miteinander kommunizieren, wird der ersten was passieren muss, ist der sichere Handschlag.

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

tls handshake

Wenn dies HTTP und nicht HTTPS wäre, wäre das erste, was der Client gesendet hätte, in etwa so:

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 ist anders. Wie ich schon sagte, der Handschlag kommt vor allem anderen. Wenn Sie sich den dritten Schritt des oben dargestellten Handshakes (Zertifikat) ansehen, muss der Server dem Client als Teil des Handshakes ein Zertifikat vorlegen, hat aber keine Ahnung, auf welchen Domänennamen der Client zugreifen möchte. Die einzige Option, die der Server hat, ist das gleiche Zertifikat jedes Mal zu senden, sein Standardzertifikat.

Sie könnten trotzdem virtuelle Hosts auf Ihrem Webserver einrichten, aber der Server würde immer dasselbe Zertifikat an jeden Client senden. Wenn Sie versucht haben, 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 also ein Client example.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 Server verwalten können, auf eine pro IP-Adresse beschränkt.

Die Lösung:

Der einfachste Weg, dieses Problem zu lösen, besteht darin, dass der Client dem Server mitteilt, auf welche Domäne er zugreifen möchte während des Handschlags. Auf diese Weise kann der Server das richtige Zertifikat bereitstellen.

Das ist genau was SNIoder Server Name Indication tut.

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

Einige ältere Webbrowser unterstützen SNI nicht. Zum Beispiel unter Windows XP ist keine einzelne Version von Internet Explorer das hat Unterstützung für SNI. Beim Zugriff auf eine Ressource über HTTPS auf einem Server, der virtuelle SNI-Hosts verwendet, wird ein generisches Zertifikat angezeigt, das dazu führen kann, dass der Browser eine Warnung oder einen Fehler anzeigt.

enter image description here

Ich habe die Dinge hier vereinfacht, um nur das Prinzip hinter dem Problem und der Lösung zu erklären. Wenn Sie eine technische Erklärung wünschen, die Wikipedia Seite oder RFC 6066 könnte als guter Ausgangspunkt dienen. Sie können auch eine aktuelle Liste der Server und Browser finden, die SNI unterstützen Wikipedia


37
2017-08-14 19:13





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

Der Client-Browser muss auch SNI unterstützen. Hier sind einige Browser, die Folgendes 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 

16
2018-02-05 00:46





Die TLS-Erweiterung für den Servernamen (RFC6066) ist erforderlich, damit namensbasierte VHosts über HTTPS arbeiten können.

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


6
2017-08-14 19:10



Zusätzlich zu Falcons Antwort erfordert IIS auch einige spezielle Änderungen, damit mehrere IIS-Sites über die gleiche IP funktionieren. Sie müssen die Konfigurationsdatei für den Server manuell bearbeiten oder ein CLI-Tool verwenden, um die Bindungsänderungen vorzunehmen. Das GUI-Tool kann dies nicht tun. In IIS wird es als Zuordnung von SSL-Zertifikaten zu Host-Headern bezeichnet. Apache hat das Problem eine Zeitlang nicht mehr gehabt. - Brent Pabst
Ah okay, das macht einiges klar. Wie können Sie wissen, ob ein Client (Browser) dies unterstützt? Wenn ich beispielsweise MSIE6 überprüfen möchte, wie kann ich das testen, ohne eine virtuelle XP-Maschine installieren zu müssen? - Luc
@ Luc de.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@Falcon SNI funktioniert nicht mit IE unter XP; Dies macht immer noch fast ein Viertel der Desktop-Internet-Nutzer aus. Ich würde es nicht "weit verbreitet" nennen, wenn ein Viertel der potenziellen Besucher nicht arbeitet. - Chris S
@MichaelHampton IE verwendet den nativen Windows Crypto Stack für SSL. XP unterstützt kein SNI, daher auch keine Version von IE unter XP. IE unterstützt nur SNI in Vista und neueren Betriebssystemen. - Chris S