Сайт ssl по умолчанию не создан для поддержки браузеров без функции sni

Пишите нам!
Архитектурная мастерская.
Продвижение сайтов от optimism.ru

Page generation time: 0.1306s (PHP: 40% — SQL: 60%) — SQL queries: 37 — GZIP disabled — Debug off

С помощью Qualys SSL Test я обнаружил, что есть клиенты (т.е. BingBot по состоянию на декабрь 2013 г.), которые не поддерживают расширение SNI.

Итак, я думаю о создании специального веб-приложения по умолчанию, которое может собирать запросы таких клиентов, но как я могу имитировать этих клиентов?

Я использую Windows 8, и у меня нет доступа к Linux, если это важно.

6 ответов

Вы можете использовать наиболее часто используемую библиотеку SSL, OpenSSL. Бинарные файлы Windows доступны для загрузки.

Команда openssl s_client -connect domain.com:443 очень хорошо подходит для проверки SSL-соединения со стороны клиента. По умолчанию он не поддерживает SNI. Вы можете добавить аргумент -servername domain.com, чтобы включить SNI.

3 Фев 2015 в 11:24

Вы можете установить Strawberry Perl, а затем использовать следующий скрипт для имитации клиента, не поддерживающего SNI:

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

3 Фев 2015 в 11:03

Подход с использованием специального веб-приложения по умолчанию просто не сработает.

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

Теперь, если клиент, не поддерживающий SNI, попытается открыть https://www.example.com, ему будет представлен сертификат от default.example.com, что приведет к ошибке сертификата. Это серьезная оговорка.

Исправление этой ошибки — создание сертификата SAN (мультидоменного), который будет включать как www.example.com, так и default.example.com. Затем, если клиент, не поддерживающий SNI, попытается открыть https://www.example.com, ему будет представлен действующий сертификат, но даже тогда его заголовок Host: все равно будет указывать на www.example.com, а его запрос будут направлены не на default.example.com, а на www.example.com.

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

4 Май 2018 в 18:16

Подобно openssl s_client — это gnutls-cli

gnutls-cli —disable-sni www.google.com

15 Июн 2017 в 10:58

Если вы используете OpenSSL 1.1.0 или более раннюю версию, используйте openssl s_client -connect $ip:$port, и OpenSSL не включит расширение SNI.

Если вы используете OpenSSL 1.1.1, вам нужно добавить флаг -noservername к openssl s_client.

9 Июн 2018 в 04:19

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

Я попытался настроить привязку протокола https по умолчанию таким же образом, как привязка протокола http по умолчанию, и используя sslFlags = «3», что означает SNI + CCS:

С указанной выше конфигурацией ни один браузер не обслуживает SSL-сертификат.

Есть ли другой способ настройки веб-сайта по умолчанию для https с использованием SNI и CCS?

Я был бы очень признателен за любую помощь в указании мне правильного направления.

2 ответа

1) Сначала я использовал IIS, чтобы создать фиктивную привязку SSL на веб-сайте по умолчанию для www.whatever.com, используя SNI и CCS.

2) Затем я вручную отредактировал эту фиктивную запись привязки в файле applicationHost.config следующим образом:

3) Наконец, я отправил свои сертификаты в папку CCS. Примерно через 5 минут новые сайты SSL были автоматически активированы IIS.

Jeow Li Huan
15 Апр 2015 в 13:19

Это случилось со мной.

Я исправил это, выполнив следующие действия:

— Найдите файл applicationHost.config в маршруте: (локальный диск): Windows / System32 / inetsrv / config (в моем случае)

— Сохраните этот файл под другим именем в качестве резервной копии, если что-то случится

— Откройте файл в текстовом редакторе и найдите следующее: (уж точно не найдешь)

— Добавьте эту строку в одну из этих привязок, которая содержит sslFlags (только один раз)

Я занимаюсь созданием веб-сайта с использованием фреймворка ASP. Net MVC 4. Мне трудно заставить SSL работать с этим (или любым другим базовым) сайтом.

Я приобрел сертификат SSL для рассматриваемого домена (назовем его просто example.com). Я вошел в IIS и настроил привязку https для веб-сайта по умолчанию для порта 443. Если я открываю версию сайта без SSL, она работает. (В данном случае сайт является стандартной стартовой страницей IIS). Если я попытаюсь получить доступ к сайту через https, время истечет, и страница не отобразится.

Я проверил с помощью netsh, что порт 443 открыт, и что на этом порту больше ничего не прослушивает. Я дважды проверил, разрешает ли брандмауэр Windows трафик на порт 443, и это так. Если я запускаю Wireshark и прослушиваю трафик на порту 443, а затем пытаюсь получить доступ к веб-странице, я получаю следующее:

Я не эксперт в интерпретации этих результатов, но, похоже, что-то все еще блокирует исходящее соединение. Опять же, обычная веб-страница http загружается нормально, но время ожидания https-версии той же страницы истекает.

Я почти в своем уме пытаюсь понять это. Есть идеи, что здесь может происходить?

Это заняло немного времени, но я наконец понял это.

Похоже, что по умолчанию доступ https к инстансу Amazon EC2 заблокирован. Это объясняет, почему не имело значения, что я делал в IIS, это не сработало. Это также объясняет, почему наличие правильной привязки, наличие правильных портов, открытых на брандмауэре, и все остальное, что я пробовал, не сработало. Это было связано с Amazon и с тем, как у них все настроено.

Чтобы включить трафик на порт 443, я сделал следующее:

Нет необходимости удалять / воссоздавать / перезапускать экземпляр. Как только я применил правила, я попытался открыть https-сайт в моем браузере на моем локальном компьютере, и это сработало.

Штеффен, спасибо за помощь.

(Связано: Настройка HTTPS в Amazon EC2)

23 Май 2017 в 15:03

Либо что-то блокирует соединения через порт 443 на пути к серверу, либо что-то блокирует ответы. На снимке экрана wirehark я вижу, что сервер и ваш клиент находятся в разных сетях, поэтому очевидно, что между ними есть хотя бы один маршрутизатор, а может быть, и другие брандмауэры. Вы можете проверить с помощью traceroute или tracepath, как далеко проходит ваш запрос (например, укажите порт 80 в одной попытке и порт 443 в другой попытке и сравните) и где может быть устройство фильтрации.

26 Янв 2014 в 21:07

In name-based virtual hosting, we host multiple domains on a single web server with one IP address. While using HTTPS, the TLS handshake happens before the server sees any HTTP headers. It is not possible for the server send information in the HTTP host header to decide which certificate to present from the same IP address.

Server With SNI, you can enable multiple SSL certificates on a single IP. It is true that you can create two or more https sites on a VPS with only one IP address.

Is the message “This site works only in browsers with SNI support” can be fixed?

Almost no. But most modern operating system and sane browsers will not show error. That thing is fixed from servers, browsers etc by patching. Fixing means the usage of available patches which allow such usage :

If you run cURL against your one multiple domain on a single IP:

and receive no error, it simply means that the thing is correct.

Security Concerns

This command will not return error (replace with own domain with one IP multiple domains) :

but this will return error (replace with own domain with one IP multiple domains) :

Try this, you’ll get no error (replace with own domain with one IP one domain) :

These kind of bug of security exploit is not uncommon with SNI :

On a non-SNI-based web server set-up multiple domain configuration with one IP would not work. There is Apache2 directive to set whether a non-SNI client is allowed to access a name-based virtual host or not. This configuration will make SNI support to force the SNI supporting browsers to allow the website :

Default is off, hence the directive not needed. But for one server one IP setup, this is more secure :

Inference is – for a very secured subdomain of your website, you can take the risk to use SSLStrictSNIVHostCheck on for single server single IP setup.

Tagged With This site works only in browsers with SNI support , browsers with sni support , site works only in browsers with sni support , sni explained , No default SSSL site has been created to support browsers without SNI capabilities it is recommended to create a default SSL site , no default site has been created to support browsers without SNI capabilities it is recommended , nexon site works on which browsers , https://thecustomizewindows com/2017/06/explained-site-works-browsers-sni-support/ , his site works only in browsers with SNI suppor , this site works only in browsers with sni support ssl labs

На сайте с 23.05.2018

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

Сознательно не буду называть компании, чтобы не делать кому-то рекламу или антирекламу. Итак.

Был на виртуальном хостинге у одного из провайдеров. Приобрел платный SSL thawte и попросил приаттачить его к домену. Сделали. В .htaccess прописал 301-й редирект, чтобы доступ был только по SSL. Захожу на сайт со своего старенького мобильного и бац — не открывается! Начинаю изучать тему и выясняется, что есть такое понятие как SNI. То есть, сайт откроется на устаревших браузерах (кроме IE на XP, так как SNI там вообще не поддерживается) только в случае если сайт живет на выделенном IP. О К. Заказываю выделенный IP, в панели управлении появилась строчка типа «SSL+IP». Лезу в мобильник, действительно все открывается. Замечу попутно, что свой SSL можно было поставить и на выделенный IP, и на общесерверные, но чтобы сайт открывался по SNI, необходим именно выделенный IP, что понятно.

На сайте с 07.06.2014

То есть ваш сайт будет открываться с IE на Windows XP, по протоколу HTTPS с выделенным IP. Есть там поддержка SNI или нет — не важно. Важен только сертификат, например, Let’s Encrypt старые браузеры не увидят.

Как у вас настроена переадресация на тот или иной протокол? Без дополнительной информации сложно что либо подсказать.

На сайте с 25.01.2017

Воспользуйтесь тестом от ssllabs.com для проверки настроек и того, где откроется а где нет.

Увеличение пинга и низкая скорость на выделенном IP это вообще нонсенс.

Для меня очень принципиально использование SNI

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

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

Нет-нет-нет, друзья, все не так. Меня здесь в очередной раз пытаются убедить, что мне все приснилось😂

Еще раз о первом провайдере, у которого все работало.

1. Сначала был куплен SSL-сертификат.

2. Затем он был добавлен на площадку хостинга на общесерверные IP. Сайт перестал открываться в WinXP на IE, который стоял у меня тогда, и перестал открываться на устаревшем браузере мобильника.

3. Прошло несколько дней. Меня такое положение дел не устроило, я заказываю выделенный IP. Как уж и к чему они там прикрепили SSL (сертификат к IP или еще как), я не знаю, но факт остается фактом:

а) я смог открыть сайт ПО IP БЕЗ РЕДИРЕКТА на доменное имя; сайт открывался по https, в адресной строчке было типа такого: https://217.21.0.124. При этом в Хроме замечательно отображался зеленый замок и надпись «Защищено».

в) сайт не открылся в IE на XP, но на XP по SNI открываются только очень крупные сайты (типа Яндекса), мой так и не открылся.

Вот цитата, которая нашлась на сайте одного из хостинг-провайдеров:

БРАУЗЕРЫ ПОДДЕРЖИВАЮЩИЕ SNI
БРАУЗЕРЫ ПК:
Internet Explorer 7 либо более поздние версии
Firefox 2
Opera 8 c TLS 1.1
Google Chrome:
Поддерживается на Windows XP, на Chrome 6 и более поздних версиях
Поддерживается на Vista и поздних версиях по умолчанию
OS X 10.5.7 в Chrome версии 5.0.342.0 и выше
Safari 2.1 и поздние версии (требует OS X 10.5.6 и выше или Windows Vista и выше).

Примечание: ни одна из версий Internet Explorer под Windows XP не поддерживает SNI.

МОБИЛЬНЫЕ БРАУЗЕРЫ:
Мобильная версия Safari для iOS 4.0
Android 3.0 (Honeycomb) и более поздние версии
Windows Phone 7

Я очень хочу доказать вам, что мне это не приснилось, но для этого мне нужно:

1. Купить виртуальный хостинг у того провайдера, о котором я говорю (теста там нет)

2. Купить сертификат (минимальная цена на thawte — 1800 в год)

3. Купить выделенный IP.

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

———- Добавлено 25.05.2018 в 02:21 ———-

Вбиваем в Хром (без указания протокола, только цифры): 148.251.3.118. Идет редирект на сайт с SSL. Как мне сделать так же?

На сайте с 19.10.2015

Настраивается редирект на nginx или apache, чтобы с IP адреса был переброс на сайт с HTTPS, ничего сложного в этом нет.

На сколько мне известно, покупается VDS, ставится любая панелька, покупается сертификат, заливается и всё готово.

Как обстоят дела с вирт.хостингами не знаю т.к. не пользуюсь

Ну. например, через файл .htaccess в корне сайта, если на сервере используется Apache с mod_rewrite:

RewriteEngine on
RewriteBase /

Вместо «domain.com» вписываете ваш домен.

На сервере nginx.

На сайте с 22.04.2006

Бывает 3 вида SSL-сертификатов:

1. Самоподписанные сертификаты, на которые ругаются браузеры, т.к. их генерят на собственном сервере, а не выдают доверенные центры сертификации. Используются для тестовых целей.

2. Обычные SSL-сертификаты с онлайн-проверкой (домена или e-mail). Такой сертификат, например, у этого форума.

3. E V SSL-сертификаты, где нужно заполнить кучу бумаг для их получения. В адресной строке они выделяются зелёным и пишется название организации для которой они выданы (обычно в интернет-банках крупных банков можно увидеть такие сертификаты).

Thawte отличаются от Let’s Encrypt только стоимостью и сроком действия. С технической точки зрения они абсолютно одинаковы.

Для того, чтобы сайт по https открывался в старых браузерах необходимо, чтобы SSL-сертификат вашего сайта был прописан первым (дефолтным) в настройках сервера. Первым его можно прописать только, если использовать отдельный IP для вашего сайта. Кроме этого в настройках веб-сервера должны быть включены такие протоколы и шифры, чтобы сайт открывался старыми браузерами (можно только TLS 1.3 с парой самых новых шифров прописать и ни в каких старых браузерах ничего открываться не будет).

Поэтому, как и советовали выше, стоит сравнить результаты ssllabs.com для вашего сайта и для того сайта, который открывается без проблем у вас в мобильном. После чего просить хостера в настройках Nginx включить протоколы и шифры, как у того сайта, где всё открывается. Но стоит заметить, что не все хостеры это могут сделать, т.к. для индивидуальных настроек они могут сказать, чтобы вы покупали VPS и делали там те настройки, которые вам нужны.

Еще дополню про ssl stapling.

Про пост выше. Кое какие глюки остались, поэтому пошел дальше и закомментил к черту строку include /usr/local/ispmgr/etc/nginx.domain;, сделал распределение сертификатов в секциях server. Из секции http нужно удалить. Об этом ниже.

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

Итак. Имеем сертификаты от StartSSL 2 штуки. Nginx обязательно обновляем до версии 1.8

Так как у меня 2 сервера с распределенной нагрузкой, я подписал их одним сертификатом, чтобы не запрашивались лишние сретификаты и не расла изза этого дополнительная нагрузка. StartSSL позволяет зарегистрировать сертификат на домен + субдомен. Ктото регает на субдомен вида www.site.ru, я же регал на subbomain.site.ru который у меня находится на 2 сервере. Отсюда возникла трабла, www получился без сертификата, что дало ошибку в неподписанном SSL на www.site.ru. Пришлось зарегать второй сертификат на этот же домен site.ru + «субдомен» WWW.site.ru Вообще наврено некорректно www называть субдоменом. Ну пускай будет им.

Я надеюсь понятно будет, мой первый сервер site.ru, второй сервер subdomain.site.ru, поэтому сертификат удачно разместился на двух физических серверах. Типа зачем? Надо мне так!

2 сертификат по сути был нужен только ради переадресации на site.ru без www. Т.к. в nginx ну и вообще по принципу работы SSL протокола, переадресация с www на без www при отсутствии второго сертификата не заработает. Можете проверить, как пример, зайдите на сбербанк онлайн или робокассу, и допишите к адресу www. Всё поймете. Для меня странно, что такие крупные конторы так наплевательски к этому отнеслись.

Короче, как сделать так чтобы при всей этой канителе заработал SSL стэплинг?

Да он собственно и без этой канители не работал, все инструкции что я находил были неполными, программерам не свойственно всё доходчиво объяснять, отсюда и инструкции как из жопы.

Разберу пример одного сервера, т.к. второй мой сервер ничем не отличается от первого кроме того что на нем установлен субдомен.

Итак, имеем ISPmanager-Lite 4.4.10.23, естественно с наикривейшей документацией.

Домены по стандарту создаем в панеле, указываем галочку SSL, выбираем сертификат введенный вручную. До этого его нужно создать в панеле с помощью копипастинга, инструкции найдете, они сносные, хотя тоже там запарка с последним нижнем полем, черт пойми какой сертификат вводить, вообще по хорошему туда нужно вводить промежуточный серверный с именем файла sub.class1.server.ca.pem, есть еще клиентский, будьте внимательны в названии. Вставлять так, чтобы на конце не было переноса и пробела, иначе ошибка.

Если SSL у вас заработал в стандартном конфиге, идем далее, настраиваем стэплинг.

Так будет выглядеть секция для редиректа с https www на https без www

add_header Strict-Transport-Security ‘max-age=15778463’; return 301 https://site.ru$request_uri; }

Как приготовить сертификат для ssl_stapling в StartSSL?

Открываем наш Notepad++

Копируем и вставляем туда код сертификата выданный на домен, при скачивании со StartSSL он имеет как правило название вашсайт.crt либо копируйте из меню Retrieve Certificate на сайте StartSSL .

Смотрим чтобы после —- не было пробелов, нажимаем энтер, копипастим следущий сертификат, с названием Class 1 Intermediate Server CA sub.class1.server.ca.pem (ВНИМАНИЕ, ТАМ СНОВА В НАЗВАНИИ server, есть такой же но client, у нас 1 класс, т.к. серт бесплатный), далее снова без пробелов и жмем энтер, с новой строки копипастим StartCom Root CA (PEM encoded) ca.pem.

Любой лишний пробел выпьет у вас крови.

Итого 3 сертификата.

Всё, сохраняем. Готово. Копируем в туже папку где остальные серты, ну и прописываем пути в nginx ssl_trusted_certificate /var/www/httpd-cert/sss/ca.pem;

service nginx restart

Забыл, это я привел пример конфиг редиректа, на основной конфиг всё тоже самое НО:

1. server_name site.ru;

2. без редиректа return 301 https://site.ru$request_uri;

3. все названия файлов сертификатов другие (это в моем случае, т.к. на www подключал другой серт, в вашем случае если серт выписали один на www и без www то все пути повторяются.

4. комментим строку отвечающую за доступ к ISP по адресу хх.хх.хх.хх:1500 #include /usr/local/ispmgr/etc/nginx.domain; иначе будете с бубном плясать как я. В IE под XP не будет работать и не будет работать редирект. браузер заматюкается на неподписанный серт ISP см. пост выше.

5.теперь доступ к ISP по адресу site.ru:1500, в том случае ели на вашем сервере 1 домен и он установлен по умолчанию к IP адресу сервера. Как проверить? Если заходим на хх.хх.хх.хх то перебрасывает на site.ru, ISP по адресу https://xx.xx.xx.xx:1500/ispmgr более не доступен, привыкайте.

6. Пункты 3-5 в вашем случае могут быть не нужны. остальные редиректы с http на https не привожу. Там главное помнить, что будет несколько секций server, отдельно под www http порты 80 и 443.

Как проверить что всё гууд?

1. Проверяем на логи ошибок nginx. Заходим на сайт, смотрим ошибки. Если есть типа 4567#0: OCSP_basic_verify() failed (SSL: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:Verify error:unable to get issuer certificate) while requesting certificate status, responder: ocsp.startssl.com значит вы накосячили.

На сайт заходить только с винды выше XP и с браузером chrome, На ХР степлинг не работает! На многих браузерах тоже.

2. Если ошибок нет, то тестим дальше.

3. Заходим в консоль, команда

Если всё правильно выдает кучу текста про сертификаты и их промежутки а также OCSP Response Data: OCSP Response Status: successful (0x0)

3. Тестим наш серт. https://www.ssllabs.com/ssltest/index.html После окончания внизу примерно будет зеленая строка OCSP stapling Yes.

4. Идем в магазин за пивом. Купите дешманское — работать перестанет.

Добрый день уважаемые читатели и гости блога, сегодня мы с вами продолжим изучать, веб сервисы на базе Windows, а именно, посмотрим, как производится настройка SSL на IIS для одного или нескольких сайтов, как с одним Ip адресом, так и с несколькими. Для выполнения этой, поставленной задачи у вас должен быть установлен веб сервер iis, на Windows Server начиная от 2008 R2 и выше, на текущий момент самый последний, это Windows Server 2016.

Настройка https сайта на IIS

И так про создание сайта iis на windows server 2012, я вам уже рассказывал, подразумевается, что он у вас есть. Далее, когда вы прописали все DNS записи, вы генерировали запрос на выпуск сертификата и уже потом получали от центра сертификации ваш сертификат, но его еще приходилось затачивать под iis, так как ему нужен формат pfx.

Еще немного теории и ограничения

Если у вас один сайт на https на вашем iis сервере, то проблем с сертификатом не возникнет, если же планируется два сайта, то тут уже есть варианты:

Установка SSL в PFX

Первым делом для создания сайтов на протоколе https, вам необходимо импортировать нужный сертификат, делается это очень просто. Вы открываете, диспетчер IIS и переходите в пункт «Сертификаты сервера»

Далее в поле «Действия» вы нажимаете импортировать.

Через обзор, указываете ваш pfx архив.

Указываете пароль, в строке «Выбрать хранилище сертификатов» укажите либо «Личный» подойдет для обычного размещение, а вот пункт «Размещение веб-служб» нужен для SNI технологии.

По сути, это и есть сложная установка SSL в iis, как вам такое.

Теперь произведем привязку SSL сертификата к нужному сайту. Для начала я проверю свой сайт на протоколе http, как видите все отлично работает.

Теперь щелкаем по нужному сайту правым кликом и выберем пункт «Изменить привязки», именно там мы и произведем настройку https в  iis.

Как видите ваш сайт по умолчанию, будет работать по протоколу http, нажимаем кнопку добавить.

Указываем для сайта:

Проверяем ваш сайт по протоколу HTTPS, если все отлично, то вы увидите закрытый замочек, это значит, что ssl сертификат установлен в IIS правильно.

Настройка нескольких HTTPS сайтов на разных ip

Предположим, что у вас есть два сайта:

Вам необходимо, чтобы каждый из них имел свой ip привязанный к DNS имени и так же отдельный сертификат, тут все просто. Вы так же поднимаете отдельные сайты, с той лишь разницей, что в поле ip адрес, указываете нужный и в поле имя узла, адрес вашего ресурса, ну и собственно нужный сертификат.

Сохраняем и проверяем, должно все работать, на любой из версий сервера IIS от 7,5 до 9.

Настройка нескольких HTTPS сайтов на одном ip

Теперь представим себе ситуацию, что у вас один внешний ip адрес, как быть, пробуем повесить все на него. В итоге один из сайтов у вас получит 404 ошибку, кто не в курсе, что это такое, то вам сюда.

Вся проблема в том, что в IIS по такому сценарию, в веб интерфейсе может работать, только сертификат на домен, формата wildcard *.pyatilistnik.org. Звездочка подразумевает, что вы можете использовать SSL на любой домен третьего уровня. Но не смейте сдаваться, есть два выхода:

Вот вам пример такого сертификата.

Если у вас wildcard, то все просто, либо через диспетчер IIS все меняете, либо через конфигурационный файл.

Откройте его, здесь хранятся настройки IIS. И можно задать биндинг на разные доменные имена:

Теперь метод, если у вас нет wildcard и только один внешний ip на сервере, подходит для IIS 7.5 и выше. Первое, что нам необходимо сделать, это узнать ID вашего сайта, делается это просто, либо через консоль диспетчер IIS

Либо все в том же файле applicationHost.config

Далее переходим в папку:

Если у вас, например, на IIS 8 и старше в данной папке нет этого файла, то вам необходимо доставить IIS Management Scripts and tools (IIS скрипты и инструменты управления ).

В Windows Server 2012 R2 файл adsutil.vbs set у меня появился в папке

cscript.exe adsutil.vbs set /w3svc/ИДСайта/SecureBindings «:443:ИмяСайта»

в моем случае это выглядит вот так

cscript.exe adsutil.vbs set /w3svc/2/SecureBindings «:443:api.ваш сайт.ru»

Теперь если при выполнении скрипта вы получаете ошибку компиляции и ваш файл adsutil.vbs это просто кракозябры, то делаем следующее.

Заходим в добавление ролей и выбираем компонент

Все проверяем теперь в браузере ваши сайты, теперь при одном ip сайты должны отвечать по своим адресам и по протоколу https. Еще у нас остается технология SNI (Server Name Indication), я ее я рассмотрю в отдельной статье, так что щелкайте по ссылке.

Добрый день уважаемые читатели и гости блога, в прошлый раз мы рассмотрели установку и настройку CMS Bitrix сама CMS очень специфичная, но тем не менее у нее есть свои хорошие применения, сегодня я хочу перенести вектор изучения, на другую веб-службу, а именно на Internet Information Services и nginx, в которых мы научимся настраивать технологию SNI (Server Name Indication) и поговорим про ее применение, на реальных примерах.

Что такое SNI (Server Name Indication)

И так давайте разберемся в понятии SNI перед тем как произвести его настройку. Начиная с 2015 года, компания Google, продвигает в массы безопасный интернет, путем внедрения сертификатов безопасности и шифрования, мотивируя вебмастеров улучшением позиций, что на практике приводит и к печальным примерам, но сегодня не об этом. Многие вебмастера начали внедрение этой технологии, и я вам рассказывал про настройку нескольких сайтов на iis 7.5, там мне пришлось по изворачиваться, чтобы запустить на одном Ip адресе два разных сайта https и с разными сертификатами, кто не читал, переходите по ссылке, чуть выше.

Так вот данную проблему решил приход технологии Server Name Indication, именно она понимает к какому веб ресурсу обращаются и пересылает сетевые запросы и пакеты на нужного адресата.  Он не поступает как обычный веб-сервер по умолчанию, в задачи которого входило принимать защищенное соединение используя информацию из первого в списке виртуального хоста (обычно это «default») и пересылать на сайт, но проблема в том что он использовал всего один SSL сертификат, как для нужного так и не для нужного сайта.

Server Name Indication (SNI) позволяет клиенту добавить имя запрашиваемого сайта в первое сообщение процедуры рукопожатия (ssl handshake). Именно эта информация позволяет серверу определить для какого сайта предназначено соединение и подсунуть его сертификат клиенту.

Поддержка SNI веб-серверами

Теперь давайте посмотрим с каких версий вы можете внедрять данную технологию:

• Apache начиная с версии 2.2.12
• Firefox моложе v.2

Настройка SSL SNI в IIS 8. 5 и выше

Начиная с Windows Server 2012 R2 у вас есть возможность использовать IIS 8.5 с поддержкой данной функции. Для ее настройки сделаем следующее. Первым делом посмотрите есть ли у вас привязанные уже SSL сертификаты к hhtps сайту и ip адресу, сделать это можно командой:

В моем примере, два сайта и у каждого свой сертификат для доступа по https, у вас будут свои. Напоминаю, что когда я рассказывал, про импортирование SSL в формате PFX на IIS сервер, я делал это в раздел «Личное» для компьютера. Для настройки SSL и TLS SNI, нам потребуется контейнер «Размещение веб-служб» (Web Hosting). Как добавить оснастку сертификаты, я вам рассказывал. Нам будет нужна именно сертификаты для компьютера. Если у вас уже есть сертификат в pfx, то это действие можете пропустить, если нет, то выгрузим его.

Делаете экспорт в pfx с экспортом закрытого ключа.

Далее переходите в раздел «Размещение веб-служб» и импортируете сертификат безопасности. через правый клик.

В мастере убеждаетесь, что делается это для локального компьютера.

Указываем наш сертификат и жмем далее.

Указываем пароль безопасности.

Указываем «Поместить все сертификаты в следующее хранилище» размещение веб-служб.

Импорт успешно выполнен.

У меня получилось вот так.

Теперь создаем новый сайт на https протоколе:

Вводим опять команды и видим, что имя хранилища сертификатов, стало Webhosting.

Вот так вот просто настраивается SNI (Server Name Indication) в IIS.

Настройка SNI в Apache

Пример двух сайтов в конфиге Apache:

Настройка SNI в nginx

Для реализации задуманного нам потребуются:

Установка сертификатов

Не имеет значение какие у вас сертификаты и где они будут расположены, но я рекомендую разместить все сертификаты в отдельном каталоге, например, /etc/keys/.

На все сертификаты и их приватные (закрытые) ключи следует установить владельца и группу root:root, а также права доступа chmod 600 для того, чтобы никто не смог похитить закрытую часть ключа.

Первоначальная инициализация nginx всегда выполняется с правами root, поэтому для сервера не будет проблемой считать конфигурационные файлы и сертификаты.

В нашем примере мы рассмотрим сертификаты srv1_example_org.crt, srv2_example_org.crt и их закрытые ключи srv1_example_org.key и srv2_example_org.key соответственно. Каждый выдан только для своего домена (srv1.example.org и srv2.example.org).

Настройка HTTPS Virtual Hosts

Создаём в каталоге /etc/nginx/sites-available/ конфиги для наших доменов api.seldon2010.ru и new.seldon2010.ru api.conf и new.conf.

sudo service nginx restart

На этом настройка завершена. Теперь nginx будет использовать разные сертификаты для сайтов api.seldon2010.ru и new.seldon2010.ru, а также выполнять принудительное перенаправление (редирект) с HTTP версии на HTTPS с кодом 301 (moved permanently).

Как видите настраивать SNI (Server Name Indication) на различных веб сервисах, не так уж и сложно, я теперь спокоен, зная, что вы владеете данной технологией.