To jest kanoniczne pytanie dotyczące hostingu wielu witryn SSL w tym samym adresie IP.

Miałem wrażenie, że każdy certyfikat SSL wymaga własnej unikalnej kombinacji adresu IP / portu. Ale odpowiedź na moje poprzednie pytanie jest sprzeczna z tym twierdzeniem.

Korzystając z informacji z tego pytania, udało mi się uzyskać wiele certyfikatów SSL do pracy na tym samym adresie IP i na porcie 443. Jestem bardzo zdezorientowany, dlaczego to działa, biorąc pod uwagę powyższe założenie i potwierdzone przez innych, że każda strona internetowa domeny SSL w ten sam serwer wymaga własnego adresu IP / portu.

Jestem podejrzliwy, że zrobiłem coś złego. Czy w ten sposób można używać wielu certyfikatów SSL?

Aby uzyskać najbardziej aktualne informacje o Apache i SNI, w tym o dodatkowych specyfikacjach RFC specyficznych dla HTTP, odwiedź Wiki Apache

FYsI: „Wiele (różnych) certyfikatów SSL w jednym adresie IP” przynosi ci magia aktualizacji TLS. Działa z nowszymi serwerami Apache (2.2.x) i stosunkowo nowymi przeglądarkami (nie znam wersji poza moją głową).

RFC 2817 (aktualizacja do TLS w HTTP / 1.1) ma krwawe szczegóły, ale w zasadzie działa dla wielu osób (jeśli nie dla większości).
Możesz jednak odtworzyć stare, funky zachowanie za pomocą s_clientpolecenia openssl (lub dowolnej „wystarczająco starej” przeglądarki).

Edytuj, aby dodać: najwyraźniej curlmoże pokazać ci, co się tutaj dzieje lepiej niż 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.

Tak, ale są pewne zastrzeżenia.

Odbywa się to poprzez Wskazanie nazwy serwera, rozszerzenie do Transport Layer Security.

Co to jest wskazanie nazwy serwera?

Wskazanie nazwy serwera ( RFC 6066 ; przestarzałe RFC 4366 , RFC 3546 ) jest rozszerzeniem Transport Layer Security, które pozwala klientowi powiedzieć serwerowi nazwę hosta, do którego próbuje dotrzeć.

SNI jest zgodny z TLS 1.0 i wyższym zgodnie ze specyfikacją, ale implementacje mogą się różnić (patrz poniżej). Nie można go używać z protokołem SSL, dlatego połączenie SNI musi negocjować TLS (patrz RFC 4346 dodatek E ). Zwykle dzieje się to automatycznie w przypadku obsługiwanego oprogramowania.

Dlaczego SNI jest potrzebny?

W zwykłym połączeniu HTTP przeglądarka informuje serwer o nazwie hosta serwera, do którego próbuje dotrzeć, używając Host:nagłówka. Umożliwia to serwerowi sieciowemu na jednym adresie IP udostępnianie treści dla wielu nazw hostów, co jest powszechnie znane jako wirtualny hosting oparty na nazwach .

Alternatywą jest przypisanie unikalnych adresów IP do każdej obsługiwanej nazwy hosta. Robiono to powszechnie w pierwszych dniach Internetu, zanim powszechnie wiadomo, że skończy się adres IP i rozpoczną się środki ochronne, i nadal tak jest w przypadku wirtualnych hostów SSL (nie używając SNI).

Ponieważ ta metoda przesyłania nazwy hosta wymaga nawiązania połączenia, nie działa z połączeniami SSL / TLS. Do czasu ustanowienia bezpiecznego połączenia serwer WWW musi już wiedzieć, jaką nazwę hosta będzie obsługiwał na kliencie, ponieważ sam serwer WWW ustanawia bezpieczne połączenie.

SNI rozwiązuje ten problem, ponieważ klient przesyła nazwę hosta w ramach negocjacji TLS, dzięki czemu serwer już wie, który host wirtualny powinien zostać użyty do obsługi połączenia. Serwer może następnie użyć certyfikatu i konfiguracji dla poprawnego wirtualnego hosta.

Dlaczego nie użyć różnych adresów IP?

Host:Nagłówek HTTP został zdefiniowany, aby umożliwić obsługę więcej niż jednego hosta WWW z jednego adresu IP z powodu braku adresów IPv4, uznanego za problem już w połowie lat dziewięćdziesiątych. We współdzielonych środowiskach hostingowych setki unikalnych, niepowiązanych stron internetowych mogą być obsługiwane przy użyciu jednego adresu IP w ten sposób, oszczędzając przestrzeń adresową.

Współdzielone środowiska hostingowe odkryły następnie, że największym konsumentem przestrzeni adresowej IP była potrzeba posiadania bezpiecznych stron internetowych w celu posiadania unikalnych adresów IP, co spowodowało potrzebę SNI jako środka zatrzymującego lukę w drodze do IPv6. Obecnie czasami trudno jest uzyskać zaledwie 5 adresów IP (/ 29) bez znacznego uzasadnienia, co często powoduje opóźnienia w wdrożeniu.

Wraz z pojawieniem się IPv6 takie techniki zachowania adresów nie są już konieczne, ponieważ do jednego hosta można przypisać więcej adresów IPv6 niż cały Internet obecnie, ale techniki te prawdopodobnie będą nadal używane w dalekiej przyszłości do obsługi starszych IPv4 znajomości.

Ostrzeżenia

Niektóre kombinacje systemu operacyjnego / przeglądarki nie obsługują SNI (patrz poniżej), więc używanie SNI nie jest odpowiednie dla wszystkich sytuacji. Witryny atakujące takie kombinacje system / przeglądarka musiałyby zrezygnować z SNI i nadal używać unikalnych adresów IP dla każdego wirtualnego hosta.

Na szczególną uwagę, żadna wersja Internet Explorera na Windows XP nie obsługuje SNI. Ponieważ ta kombinacja nadal stanowi znaczną (ale stale malejącą; około 16% ruchu internetowego w grudniu 2012 r. Według NetMarketShare) część ruchu internetowego, SNI byłby nieodpowiedni dla witryny kierowanej do tych grup użytkowników.

Wsparcie

Wiele powszechnie używanych pakietów oprogramowania obsługuje SNI.

(Pominięcie tej listy niekoniecznie oznacza brak wsparcia; oznacza to, że było ograniczenie, ile mógłbym wpisać, lub nie mogłem szybko znaleźć informacji w wyszukiwaniu. Jeśli Twojego pakietu oprogramowania nie ma na liście, wyszukiwanie jego nazwa plus snipowinna ujawniać, czy istnieje wsparcie i jak je skonfigurować).

Obsługa bibliotek

Większość pakietów zależy od zewnętrznej biblioteki zapewniającej obsługę SSL / TLS.

• GNU TLS
• JSSE (Oracle Java) 7 lub nowszy, tylko jako klient
• libcurl 7.18.1 lub wyższy
• NSS 3.1.1 lub nowszy
• OpenSSL 0.9.8j lub wyższy
  • OpenSSL 0.9.8f lub wyższy, z flagami konfiguracji
• Qt 4,8 lub wyższy

Obsługa serwera

Większość aktualnych wersji popularnego oprogramowania serwerowego obsługuje SNI. Instrukcje instalacji są dostępne dla większości z nich:

• Apache 2.2.12 lub nowszy
• Serwer Apache Traffic Server 3.2.0 lub nowszy
• Cherokee
• HAProxy 1.5 lub nowszy
• IIS 8.0 lub nowszy
• lighttpd 1.4.24 lub wyższy
• LiteSpeed ​​4.1 lub nowszy
• nginx 0,5.32 lub wyższy

Obsługa klienta

Większość obecnych przeglądarek internetowych i agentów użytkownika wiersza poleceń obsługuje SNI.

Pulpit

• Chrome 5 lub nowszy
  • Chrome 6 lub nowszy w systemie Windows XP
• Firefox 2 lub nowszy
• Internet Explorer 7 lub nowszy, działający w systemie Windows Vista / Server 2008 lub nowszym
  • Internet Explorer w systemie Windows XP nie obsługuje SNI niezależnie od wersji IE
• Konqueror 4.7 lub nowszy
• Opera 8 lub nowsza (może wymagać włączenia TLS 1.1 do działania)
• Safari 3.0 w systemie Windows Vista / Server 2008 lub nowszym albo Mac OS X 10.5.6 lub nowszym

mobilny

• Przeglądarka Android w wersji 3.0 Honeycomb lub wyższej
• iOS Safari na iOS 4 lub nowszym
• Windows Phone 7 lub nowszy

Wiersz poleceń

• cURL 7.18.1 lub wyższy
• wget 1.14 lub wyższy (Dystrybucje mogły mieć backportową łatkę do obsługi SNI)

Bez wsparcia

• Przeglądarka BlackBerry
• Internet Explorer (dowolna wersja) w systemie Windows XP

(Uwaga: niektóre informacje na temat tej odpowiedzi uzyskano z Wikipedii ).

Problem:

Gdy klient WWW i serwer WWW rozmawiają ze sobą przez HTTPS, pierwszą rzeczą, która musi się zdarzyć, jest bezpieczny uścisk dłoni.

Oto uproszczony przykład takiego uścisku dłoni:

Gdyby to był HTTP, a nie HTTPS, pierwszą rzeczą, którą klient wysłałby, byłoby coś takiego:

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

Umożliwiło to utworzenie wielu wirtualnych hostów na jednym adresie IP, ponieważ serwer dokładnie wie, do jakiej domeny chce uzyskać dostęp klient, czyli example.com.

HTTPS jest inny. Jak powiedziałem wcześniej, uścisk dłoni jest najważniejszy. Jeśli spojrzysz na trzeci krok uzgadniania zilustrowany powyżej (Certyfikat), serwer musi przedstawić klientowi certyfikat jako część uzgadniania, ale nie ma pojęcia, do jakiej nazwy domeny klient chce uzyskać dostęp. Jedyną opcją serwera jest wysyłanie za każdym razem tego samego certyfikatu, domyślnego certyfikatu.

Nadal można skonfigurować wirtualne hosty na serwerze WWW, ale serwer zawsze wysyła ten sam certyfikat do każdego klienta. Jeśli próbujesz hostować zarówno witryny example.com, jak i example.org na swoim serwerze, serwer zawsze wysyła certyfikat na example.com, gdy klient zażąda połączenia HTTPS. Tak więc, gdy klient zażąda example.org przez ustanowione połączenie HTTPS, tak by się stało:

Ten problem skutecznie ogranicza liczbę domen, które można serwerować przez HTTPS, do jednej na adres IP.

Rozwiązanie:

Najprostszym sposobem rozwiązania tego problemu jest poinformowanie serwera, do której domeny chce uzyskać dostęp podczas uzgadniania . W ten sposób serwer może podać poprawny certyfikat.

To właśnie robi SNI lub Wskazanie nazwy serwera.

W przypadku SNI klient wysyła nazwę serwera, do którego chce uzyskać dostęp, w ramach pierwszej wiadomości, kroku „Witaj klienta” na powyższym schemacie uzgadniania.

Niektóre starsze przeglądarki internetowe nie obsługują SNI. Na przykład w systemie Windows XP nie ma jednej wersji programu Internet Explorer , która obsługuje SNI. Podczas uzyskiwania dostępu do zasobu przez HTTPS na serwerze, który korzysta z wirtualnych hostów SNI, zostanie wyświetlony ogólny certyfikat, który może spowodować, że przeglądarka wyświetli ostrzeżenie lub błąd.

Upraszczam tutaj rzeczy, aby wyjaśnić zasadę problemu i rozwiązanie. Jeśli potrzebujesz bardziej technicznego wyjaśnienia, strona wikipedia lub RFC 6066 może służyć jako dobry punkt wyjścia. Możesz również znaleźć aktualną listę serwerów i przeglądarek obsługujących SNI na wikipedii

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

Przeglądarka klienta musi również obsługiwać SNI. Oto niektóre przeglądarki, które:

* 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 

Rozszerzenie TLS ze wskazaniem nazwy serwera (RFC6066) jest wymagane, aby vhosty oparte na nazwach działały przez HTTPS.

Rozszerzenie jest szeroko wdrażane i nie mam jeszcze żadnych problemów z bieżącym oprogramowaniem, ale istnieje szansa, że ​​niektórzy klienci (ci, którzy go nie obsługują) zostaną przekierowani do Twojej domyślnej witryny, jeśli zależysz od SNI.