Отключение SNI для определенного виртуального хоста на Apache

У нас есть веб-сервер с парой интернет-IP.

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

У нас есть очень популярный сайт, на котором значительное количество пользователей работают с сильно устаревшими браузерами, поэтому для нас это очень важно.

Запуск Apache 2.2 (2.2.15-47.el6_7) на CentOS 6.

Как заявляли другие, просто поместите первый сайт в качестве первого виртуального хоста, и он будет работать независимо от того, включен SNI или нет:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server1.key
   SSLCertificateFile /ssl/server1.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server2.key
   SSLCertificateFile /ssl/server2.crt

</VirtualHost>

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

Однако есть возможность предоставить доступ к все пользователи для все ваши сайты, несмотря на очевидную проблему с SNI, если у вас есть единый сертификат, охватывающий все поля альтернативных имен субъектов сайтов.

Затем у вас может быть два виртуальных хоста, использующих один и тот же ключ и сертификат:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

Таким образом, у вас есть один и тот же ключ и сертификат для двух сайтов (или трех, или более, если хотите).

Таким образом, www.site1.com всегда работает, даже без поддержки SNI, это хост по умолчанию.

Для www.site2.com становится интереснее:

Для браузеров, поддерживающих SNI, они предоставляют имя сервера и сразу переходят к конфигурации виртуального хоста site2, и это работает.
Для браузеров, которые не поддерживают SNI, по умолчанию используется конфигурация site1, которая возвращает сертификат, но, поскольку сертификат работает для обоих сайтов, это нормально. После завершения согласования SSL поступает первый веб-запрос, но поскольку на этот раз серверу присваивается имя сервера, он может правильно обслуживать документ из каталога / site2 /.

Таким образом, это работает, потому что соединение https включает в себя два различных и не связанных между собой шага: 1) выполнение согласования SSL и 2) запрос документа с использованием этого SSL-соединения, и эти два шага не обязательно должны выполняться с одного и того же виртуального хоста (хотя большинство людей считает, что это так. ).

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

Я считаю, что это удобное небольшое обходное решение, особенно для серверов разработчиков, где я могу разместить несколько сайтов на одном IP-адресе, где я использую самозаверяющие центы с несколькими URL-адресами в поле альтернативного имени субъекта.

Вы не «отключаете» SNI на стороне сервера - вы даже не можете контролировать, отправляет ли клиент расширение или нет. Все, что вы можете сделать, это определить, как ваш сервер реагирует на наличие (или отсутствие) информации SNI.

Обычно, когда сервер получает запрос, в котором отсутствует информация об SNI, он выбирает один из сертификатов, доступных для предоставления клиенту. Для Apache это будет первый vhost для пары адрес / порт, которая прослушивается.

Что касается того, иметь ли отдельный адрес «не-SNI» для сайта, который вы хотите сделать безопасным для доступа без SNI, я не думаю, что это важно. Вы также можете сохранить ценный IPv4-адрес и просто поместить их все на один IP-адрес. Любой, кто получает доступ к сайту только для SNI из браузера, не поддерживающего SNI, в любом случае получит те же предупреждения о сертификате, независимо от того, совпадает ли его адрес с сайтом без SNI или нет. Единственное, на что следует обратить внимание, это то, хотите ли вы, чтобы сертификат для сайта, который поддерживает клиентов, отличных от SNI, предоставлялся клиентам без поддержки SNI, когда они обращаются к сайту, поддерживающему только SNI.

Я так много раз набирал "SNI", что это начинает терять всякий смысл ...