Несколько доменов SSL на одном и том же IP-адресе и том же порту?

  

Это Канонический вопрос о размещении нескольких сайтов SSL на одном и том же IP-адресе.

У меня создалось впечатление, что каждый сертификат SSL требует, чтобы это была уникальная комбинация IP-адресов /портов. Но ответ на предыдущий вопрос, который я опубликовал , не согласуется с этим утверждением.

Используя информацию из этого Вопроса, я смог получить несколько сертификатов SSL для работы на одном и том же IP-адресе и на порту 443. Я очень смущен тем, почему это работает, учитывая предположение выше и подкрепленное другими, что каждый домен SSL веб-сайт на том же сервере требует наличия собственного IP /порта.

Я подозрюю, что сделал что-то не так. Можно ли использовать несколько SSL-сертификатов таким образом?

105 голосов | спросил John 5 FebruaryEurope/MoscowbFri, 05 Feb 2010 01:36:43 +0300000000amFri, 05 Feb 2010 01:36:43 +030010 2010, 01:36:43

5 ответов


67
  

Для получения самой последней информации об Apache и SNI, включая дополнительные HTTP-специфические RFC, обратитесь к Apache Wiki


FYsI: «Множество (разных) сертификатов SSL на одном IP-адресе приносит вам волшебство TLS Upgrading. Он работает с более новыми серверами Apache (2.2.x) и достаточно современными браузерами (не знаю версий с верхней части моей головы).

RFC 2817 (обновление до TLS в HTTP /1.1) содержит детали gory, но в основном это работает для многих людей (если не большинства).
Вы можете воспроизвести старое напуганное поведение с помощью s_client

Изменить для добавления: видимо curl может показать вам, что здесь происходит лучше, чем openssl:


SSLv3

[email protected]% 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

[email protected]% 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.
ответил voretaq7 5 FebruaryEurope/MoscowbFri, 05 Feb 2010 02:46:52 +0300000000amFri, 05 Feb 2010 02:46:52 +030010 2010, 02:46:52
95

Да, но есть некоторые оговорки.

Это выполняется с помощью указателя имени сервера, расширения для безопасности транспортного уровня.

Что такое индикация имени сервера?

Указание имени сервера ( RFC 6066 ; obsoleted RFC 4366 , RFC 3546 ) является расширением Transport Layer Security , который позволяет клиенту сообщать серверу имя хоста, к которому он пытается связаться.

SNI совместим с TLS 1.0 и выше в соответствии со спецификацией, но реализации могут отличаться (см. ниже). Он не может использоваться с SSL, поэтому соединение должно согласовывать TLS (см. приложение RFC 4346 E ) для SNI для использования. Обычно это происходит автоматически с поддерживаемым программным обеспечением.

Почему требуется SNI?

В обычном HTTP соединении браузер сообщает серверу имени хоста сервера пытается достичь использования заголовка Host:. Это позволяет веб-серверу на одном IP-адресе обслуживать контент для нескольких имен хостов, который обычно называется имя- основанный на виртуальном хостинге .

Альтернативой является назначение уникальных IP-адресов для каждого обслуживаемого веб-хоста. Это обычно делалось в самые ранние дни Интернета, прежде чем стало известно, что IP-адреса будут исчерпаны, и меры по сохранению начались, и все еще делается таким образом для виртуальных хостов SSL (не используя SNI).

Поскольку этот способ передачи имени хоста требует установления соединения, он не работает с соединениями SSL /TLS. К моменту установления безопасного соединения веб-сервер уже должен знать, какое имя хоста он будет обслуживать для клиента, потому что сам веб-сервер настраивает безопасное соединение.

SNI решает эту проблему, когда клиент передает имя хоста как часть согласования TLS, так что сервер уже знает, какой виртуальный хост должен использоваться для обслуживания соединения. Затем сервер может использовать сертификат и конфигурацию для правильного виртуального хоста.

Почему бы не использовать разные IP-адреса?

Заголовок HTTP Host: был определен, чтобы позволить обслуживать более одного веб-хоста от одного IP-адреса из-за нехватки адресов IPv4, признанных проблемой уже в середине середины, 1990-й года. В общедоступных средах веб-хостинга сотни уникальных несвязанных веб-сайтов могут обслуживаться одним IP-адресом таким образом, сохраняя адресное пространство.

Затем совместно используемые среды размещения обнаружили, что крупнейшим потребителем пространства IP-адресов является необходимость обеспечения безопасных веб-сайтов уникальными IP-адресами, что создает потребность в SNI в качестве меры блокировки на пути к IPv6. Сегодня иногда бывает трудно получить всего 5 IP-адресов (29) без существенного обоснования, что часто приводит к задержкам развертывания.

С появлением IPv6 такие методы сохранения адресов больше не нужны, поскольку один хост может иметь больше назначенных ему IPv6-адресов, чем сегодня весь Интернет, но методы, вероятно, все еще будут использоваться далеко в будущем для сервисные устаревшие соединения IPv4.

Предостережения

Некоторые комбинации операционной системы /браузера не поддерживают SNI (см. ниже), поэтому использование SNI не подходит для всех ситуаций. Сайтам, нацеленным на такие комбинации системы /браузера, пришлось бы отказаться от SNI и продолжать использовать уникальные IP-адреса для каждого виртуального хоста.

Особо следует отметить, что ни одна версия Internet Explorer в Windows XP не поддерживает SNI. Поскольку эта комбинация по-прежнему представляет собой значительную (но неуклонно уменьшающуюся, примерно 16% интернет-трафика в декабре 2012 года по NetMarketShare) части интернет-трафика, SNI будет неприемлемым для сайта, ориентированного на эти группы пользователей.

Поддержка

Многие, но не все, обычно используемые пакеты программного обеспечения поддерживают SNI.

(Отсутствие в этом списке необязательно означает отсутствие поддержки, это означает, что существует ограничение на то, как я могу печатать, или я не мог быстро найти информацию в поиске. Если ваш пакет программного обеспечения не является перечисленные, ища его имя плюс sni, должны показать, существует ли поддержка и как ее настроить.)

Поддержка библиотеки

Большинство пакетов зависят от внешней библиотеки для поддержки SSL /TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 или выше, только как клиент
  • libcurl 7.18.1 иливыше
  • NSS 3.1.1 или выше
  • OpenSSL 0.9.8j или выше
    • OpenSSL 0.9.8f или выше, с флагами конфигурации
  • Qt 4.8 или выше

Поддержка сервера

Большинство современных версий популярного серверного программного обеспечения поддерживают SNI. Инструкции по установке доступны для большинства из них:

Поддержка клиентов

Большинство современных веб-браузеров и пользовательских агентов командной строки поддерживают SNI.

Desktop

  • Chrome 5 или выше
    • Chrome 6 или выше в Windows XP
  • Firefox 2 или выше
  • Internet Explorer 7 или выше, работающий в Windows Vista /Server 2008 или выше
    • Internet Explorer в Windows XP не поддерживает SNI независимо от версии IE
  • Konqueror 4.7 или выше
  • Opera 8 или выше (может потребоваться поддержка TLS 1.1)
  • Safari 3.0 в Windows Vista /Server 2008 или выше или Mac OS X 10.5.6 или более поздняя версия

Мобильный

  • Android Browser на 3.0 Honeycomb или выше
  • iOS Safari на iOS 4 или выше
  • Windows Phone 7 или выше

Командная строка

  • cURL 7.18.1 или выше
  • wget 1.14 или выше (дистрибутивы могут использовать патч для поддержки SNI)

Нет поддержки

  • Браузер BlackBerry
  • Internet Explorer (любая версия) в Windows XP

(Примечание. Некоторая информация для этого ответа была получена из Wikipedia .)

ответил Michael Hampton 15 AM00000030000003931 2012, 03:05:39
36

Проблема:

Когда веб-клиент и веб-сервер общаются друг с другом через HTTPS, очень первая вещь, которая должна произойти, - это безопасное квитирование.

Вот упрощенный пример такого рукопожатия:

tls handshake

Если это HTTP, а не HTTPS, первое, что отправил клиент, было бы примерно таким:

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

Это сделало возможным несколько виртуальных хостов на одном IP-адресе, так как сервер точно знает, к какому домену клиент обращается, а именно example.com.

HTTPS отличается. Как я уже говорил, рукопожатие приходит прежде всего. Если вы посмотрите на третий шаг рукопожатия, описанный выше (сертификат), сервер должен представить сертификат клиенту как часть рукопожатия, но не знает, какое доменное имя клиент пытается получить. Единственный вариант, который имеет сервер - это отправлять один и тот же сертификат каждый раз, его сертификат по умолчанию.

Вы все равно можете настроить виртуальные хосты на своем веб-сервере, но сервер всегда будет отправлять один и тот же сертификат каждому клиенту. Если вы попытались разместить сайты example.com и example.org на своем сервере, сервер всегда будет отправлять сертификат на example.com, когда клиент запрашивает соединение HTTPS. Поэтому, когда клиент запрашивает example.org через установленное соединение HTTPS, это произойдет:

введите описание изображения здесь>> </p>

<p> Эта проблема эффективно ограничивает количество доменов, на которые вы можете переходить через HTTPS на один IP-адрес. </p>

<p> <strong> Решение: </strong> </p>

<p> Самый простой способ решить эту проблему - это указать клиенту сервер, на какой домен он хочет получить доступ  во время рукопожатия . Таким образом, сервер может обслуживать правильный сертификат. </p>

<p> Это именно то, что <a href= SNI или указатель имени сервера.

С SNI клиент отправляет имя сервера, к которому он хочет получить доступ, как часть первого сообщения, шаг «Клиент Hello» в диаграмме рукопожатия выше.

Некоторые старые веб-браузеры не поддерживают SNI. Например, в Windows XP нет единственная версия Internet Explorer , которая поддерживает SNI. При доступе к ресурсу через HTTPS на сервере, использующем виртуальные хосты SNI, вам будет предоставлен общий сертификат, который может привести к тому, что браузер отобразит предупреждение или ошибку.

введите описание изображения здесь

Я упростил здесь все, чтобы просто объяснить принцип проблемы и решение. Если вы хотите получить более техническое объяснение, страница wikipedia или RFC 6066 может послужить хорошей отправной точкой. Вы также можете найти список серверов и браузеров, поддерживающих SNI, на wikipedia

ответил Kenny Rasschaert 14 PM000000110000005931 2012, 23:13:59
16

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

Клиентский браузер также должен поддерживать SNI. Вот некоторые браузеры, которые делают:

* 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 
ответил Craig 5 FebruaryEurope/MoscowbFri, 05 Feb 2010 03:46:39 +0300000000amFri, 05 Feb 2010 03:46:39 +030010 2010, 03:46:39
6

Расширение TLS сервера (RFC6066) требуется для того, чтобы хосты, основанные на имени, работали над HTTPS.

Расширение широко внедрено, и мне еще предстоит столкнуться с любыми проблемами с текущим программным обеспечением, но есть вероятность, что некоторые клиенты (те, кто не поддерживает его) будут перенаправлены на ваш сайт по умолчанию, если вы зависите от SNI.

ответил Falcon Momot 14 PM000000110000000731 2012, 23:10:07

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132