У меня сложилось впечатление, что для каждого SSL-сертификата требуется своя уникальная комбинация IP-адрес/порт. Но информация из интернета противоречит этому утверждению.
Используя информацию из этого вопроса, я смог заставить несколько SSL-сертификатов работать на одном IP-адресе и на порту 443. Я очень озадачен тем, почему это работает, учитывая предположение, высказанное выше, что каждый SSL-доменный сайт на одном сервере требует свой собственный IP/порт.
Я подозреваю, что сделал что-то не так. Можно ли таким образом использовать несколько SSL-сертификатов?
Ответ 1
Для получения наиболее актуальной информации об Apache и SNI, включая дополнительные RFC по HTTP, пожалуйста, обратитесь к Apache Wiki.
К вашему сведению: «Несколько (разных) SSL-сертификатов на одном IP» — это «магия» TLS Upgrading. Это работает с новыми серверами Apache (2.2.x) и достаточно новыми браузерами.
RFC 2817 (обновление до TLS в HTTP/1.1) содержит подробную информацию, но в основном это работает для многих людей (если не для большинства).
Однако вы можете воспроизвести старое поведение с помощью команды s_client от openssl (или любого «достаточно старого» браузера).
Ответ 2
Да, но есть некоторые предостережения.
Это достигается с помощью указания имени сервера, расширения безопасности транспортного уровня.
Что такое указание имени сервера?
Указание имени сервера (RFC 6066; устаревшие RFC 4366, RFC 3546) — это расширение Transport Layer Security, которое позволяет клиенту сообщать серверу имя узла, с которым он пытается связаться.
SNI совместим с TLS 1.0 и выше в соответствии со спецификацией, но реализация может отличаться (см. ниже). Он не может использоваться с SSL, поэтому для использования SNI соединение должно согласовать TLS (см. RFC 4346 приложение E). Обычно это происходит автоматически при использовании поддерживаемого программного обеспечения.
Зачем нужен 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 не поддерживает SNI. Поскольку эта комбинация все еще представляет собой значительную (но неуклонно снижающуюся; около 16% интернет-трафика по данным 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 или выше, с флагами configure
Qt 4.8 или выше
Поддержка серверов
Большинство современных версий популярного серверного программного обеспечения поддерживают SNI. Для большинства из них доступны инструкции по настройке:
Apache 2.2.12 или выше
Apache Traffic Server 3.2.0 или выше
Cherokee
HAProxy 1.5 или выше
IIS 8.0 или выше
lighttpd 1.4.24 или выше
LiteSpeed 4.1 или выше
nginx 0.5.32 или выше
Поддержка клиентов
Большинство современных веб-браузеров и агентов командной строки поддерживают SNI.
Ответ 3
Проблема:
Когда веб-клиент и веб-сервер общаются друг с другом по HTTPS, самое первое, что должно произойти, — это безопасное рукопожатие.
Если бы это был HTTP, а не HTTPS, первое, что послал бы клиент, было бы что-то вроде этого:
GET /index.html HTTP/1.1
Хост: example.com
Это сделало возможным использование нескольких виртуальных хостов на одном IP-адресе, поскольку сервер точно знает, к какому домену хочет получить доступ клиент, а именно к example.com.
HTTPS отличается. Сервер должен представить клиенту сертификат как часть рукопожатия, но он не знает, к какому доменному имени пытается получить доступ клиент. Единственный вариант, который есть у сервера, — это отправлять каждый раз один и тот же сертификат, свой сертификат по умолчанию.
Вы все еще можете настроить виртуальные хосты на своем веб-сервере, но сервер всегда будет отправлять один и тот же сертификат каждому клиенту. Если бы вы попытались разместить на своем сервере сайты example.com и example.org, сервер всегда отправлял бы сертификат для example.com, когда клиент запрашивает HTTPS-соединение. Поэтому, когда клиент запрашивает сайт example.org через установленное HTTPS-соединение, происходит следующее:
Эта проблема эффективно ограничивает количество доменов, которые вы можете обслуживать через HTTPS, до одного на IP-адрес.
Решение:
Самый простой способ решения этой проблемы заключается в том, чтобы клиент сообщил серверу, к какому домену он хочет получить доступ во время рукопожатия. Таким образом, сервер сможет выдать нужный сертификат.
Именно это и делает SNI или указание имени сервера.
При использовании SNI клиент отправляет имя сервера, к которому он хочет получить доступ, как часть первого сообщения.
Некоторые старые веб-браузеры не поддерживают SNI. Например, на Windows XP нет ни одной версии Internet Explorer, которая поддерживала бы SNI. При доступе к ресурсу по HTTPS на сервере, использующем виртуальные узлы SNI, вам будет представлен типовой сертификат, что может вызвать в браузере предупреждение или ошибку.
Здесь я упростил ситуацию, чтобы просто объяснить принцип, лежащий в основе проблемы и ее решения. Если вы хотите получить более техническое объяснение, страница Википедии или RFC 6066 могут послужить хорошими отправными точками. Вы также можете найти актуальный список серверов и браузеров, поддерживающих SNI, в Википедии.
Ответ 4
Расширение TLS с указанием имени сервера (RFC6066) требуется для работы vhosts на основе имен через HTTPS. Расширение широко применяется, и я еще не сталкивался с какими-либо проблемами в текущем программном обеспечении, но есть вероятность, что некоторые клиенты (не поддерживающие его) будут перенаправлены на ваш сайт по умолчанию, если вы полагаетесь на SNI.
Linux
