Вопросы Теги

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

Для получения по запросу эффективного uid используют эту команду:

id -u

Если результат ‘0’ затем, сценарий или работает как корень или использует sudo. Можно осуществить проверку путем выполнения чего-то как:

if [[ $(/usr/bin/id -u) -ne 0 ]]; then
    echo "Not running as root"
    exit
fi
109
задан 13 April 2017 в 15:14
5 ответов

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

FYsI: "Несколько (различных) сертификатов SSL на одном IP" принесены Вам волшебством Обновления TLS. Это работает с более новыми серверами Apache (2.2.x), и довольно недавние браузеры (не знайте версии первое, что пришло на ум).

RFC 2817 (обновляющий до TLS в HTTP/1.1) имеет окровавленные детали, но в основном он работает на большое количество людей (если не большинство).
Можно воспроизвести старое броское поведение с openssl's s_client команда (или любой "достаточно взрослый" браузер) все же.

Редактирование для добавления: по-видимому, curl может показать Вам, что происходит здесь лучше, чем 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
ответ дан 28 November 2019 в 19:20
  • 1
    That' s очень полезный - Спасибо! Какая-либо информация о том, как настроить Apache для TLS вместо SSL? –  Josh 5 February 2010 в 01:56
  • 2
    Я думаю, что Apache 2.2 просто нужно было включить биты TLS в его списке шифра. I' ll допускают I' ve никогда не видят целый " Обновление от SSL до TLS" бит в действии до этих двух сайтов все же. Мое понимание документов TLS - это it' s допустимое (но необычный) ситуация для согласования этого вида обновления... –  voretaq7 5 February 2010 в 02:01
  • 3
    Это - первый раз I' ve, когда-либо замеченный это любой и I' m, все еще пытаясь вытянуть мою челюсть от пола... –  Josh 5 February 2010 в 02:04
  • 4
    Хорошо мой ответ, просто утроенный в длине - По-видимому, завихряется, может сделать и SSLv3 и согласования TLSv1, таким образом, я могу показать отказ & успех. Мне жаль, что у меня не было отладчика протокола, удобного для показа волшебной части все же. (Также протестированный и счастливый сообщить об этом johnlai2004' s сервер правильно отклоняет соединения SSLv2 :-) –  voretaq7 5 February 2010 в 02:18
  • 5
    Это чрезвычайно полезно, и я надеюсь, что johnlai2004 принимает Ваш ответ.Большое спасибо! –  Josh 5 February 2010 в 02:52

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
16
ответ дан 28 November 2019 в 19:20

Да, но есть некоторые предостережения.

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

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

Имя сервера Указание ( RFC 6066 ; устаревшее 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.

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

  • 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 в версии 3.0 Honeycomb или выше
    • iOS Safari в iOS 4 или выше
    • Windows Phone 7 или выше

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

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

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

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

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

    97
    ответ дан 28 November 2019 в 19:20

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

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

    6
    ответ дан 28 November 2019 в 19:20

    Проблема:

    Когда веб-клиент и веб-сервер общаются друг с другом по 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-соединение, это может произойти:

    enter image description here

    Эта проблема фактически ограничивает количество доменов, которые вы можете обслуживать по HTTPS, до одного на каждый IP-адрес.

    Решение:

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

    Это именно то, что делает SNI или указание имени сервера.

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

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

    enter image description here

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

    37
    ответ дан 28 November 2019 в 19:20

    Теги

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