Нет необходимости включать SNI для нескольких сайтов SSL на одном IP-адресе, но с использованием одного и того же сертификата подстановки?
У меня есть сервер IIS, на котором размещен:
example.com/ www.example.com
sub1.example.com
sub2.example.com
Они перечислены как 3 отдельных сайта в IIS, все привязаны к одному и тому же IP через HTTPS на 443. Но все они используют один и тот же сертификат SSL, который является сертификатом подстановки, охватывающим * .example.com
В этом сценарии, насколько я понимаю, SNI не нужен, потому что какой бы сертификат сервер ни обслужил для любого запроса (который является одним и тем же сертификатом), все равно будет работать для всех сайтов, правильно? Я сам протестировал его, и, похоже, он работает, но я просто хочу убедиться, что это не вызовет неожиданных болезненных результатов для определенных пользователей (я не хочу использовать SNI, если это возможно, потому что мне нужна поддержка Windows XP для этих сайты)
Из любопытства я действительно хочу знать, когда у вас есть такая настройка (несколько сайтов через SSL на одном IP-адресе, но без поддержки SNI), как именно IIS решает, какой сертификат обслуживать (первая привязка 443 к IP-адресу? Или последний использованный?)
Кроме того, если эта настройка работает, в будущем, если я добавлю example.org в тот же IIS сервер и используя другой сертификат SSL, могу ли я включить SNI только для example.org и не влиять на остальные 3 сайта?
Практическое правило состоит в том, что на уровне HTTP API
- вы можете привязать одиночный сертификат к IP: 443 как сопоставление на основе IP.
- Вы можете привязать сертификат к домену: 443 как сопоставление SNI.
Такие сопоставления можно визуально проанализировать с помощью Jexus Manager .
Когда начинается квитирование SSL / TLS, сопоставления SNI будут сканироваться в первую очередь на соответствие хосту имя в запросе (из браузеров, поддерживающих SNI). Если сопоставление SNI не соответствует, выполняется сканирование сопоставления на основе IP. Это порядок разрешения.
Сопоставления создаются и обновляются при настройке сайтов в диспетчере IIS. Однако такие сопоставления в HTTP API отделены от конфигурации IIS. Они могут существовать, даже если сайты в IIS удалены.
В вашем случае, поскольку у вас есть только шаблонный сертификат, настройка нескольких сайтов в IIS Manager не перезапишет сопоставление на основе IP и должна работать безупречно. .
Однако, когда вы пытаетесь настроить второй домен с другим сертификатом, вы не можете использовать тот же IP-адрес (поскольку это сопоставление IP: 443 уже существует). Если вы принудительно настроите это в диспетчере IIS, предыдущий сертификат должен быть перезаписан. Конечно, тогда можно использовать отображение SNI.
Технически говоря, нет, SNI не требуется, потому что все ваши веб-сайты имеют один и тот же сертификат. IIS достаточно умен (кажется, по крайней мере), чтобы различать веб-сайты, использующие Host: HTTP-заголовок на клиентах, отличных от SNI (и, возможно, даже в SNI- включенных клиентов), поэтому все работает, как ожидалось.
Для «приоритета» сертификата вы можете увидеть, какой сертификат используется, выполнив netsh http show sslcert и сертификат по умолчанию (для не-SNI клиент) можно выбрать, отключив параметр Требовать указание имени сервера для этого конкретного веб-сайта (в окне настроек привязок веб-сайтов ). Подробнее здесь: https://stackoverflow.com/questions/19565961/default-certificate-for-sni-server-name-indication
Это также должно ответить на ваш третий вопрос: если вы добавите еще один веб-сайт с SNI, на существующих веб-сайтах не будет никаких изменений (конечно, при использовании другого домена и другого сертификата example.org будет доступен только для клиентов с поддержкой SNI )