Windows server 2018 r2 iis настройка: : Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8

Содержание

IIS и FTP, web и seo

Category Archives: IIS и FTP, web и seo

18.12.2022 IIS и FTP, web и seo No comments

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали, как можно установить Internet Information Services. Сегодня я хочу продолжить данную тему и показать вам где хранятся файлы журналов IIS, так как файлы журналов Internet Information Services (IIS) содержат ценную информацию об использовании и состоянии Web приложений. Однако не всегда легко найти, где они находятся, чтобы определить важные аспекты использования приложения, например, когда были сделаны запросы к серверу, кем и другие проблемы пользовательского трафика. Давайте разбираться.

10.07.2020 IIS и FTP, web и seo 2 комментария

Добрый день! Уважаемые читатели и гости одного из крупнейших IT порталов России Pyatilistnik.org. В прошлый раз мы с вами научились восстанавливать библиотеку vcruntime140_1. dll в Windows и тем самым восстановили работу ряда приложений. В сегодняшней публикации я рассмотрю ситуацию, когда у вас не отвечает и не работает сайт RDWeb на вашей терминальной ферме. Думаю это будет интересный момент для начинающих системных администраторов.

03.07.2020 IIS и FTP, web и seo 3 комментария

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами научились чинить две вещи в Windows 10, это пресловутый черный экран и ошибку запуска в приложениях из-за отсутствия библиотеки vcruntime140.dll. Двигаемся дальше и сегодня решим еще один интересный пазл с веб сервисом IIS и ошибкой «HTTP Error 503. The service is unavailable«. Думаю, что мои грабли будут вам весьма интересны.

16.11.2019 IIS и FTP, web и seo No comments

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik. org. В прошлый раз мы с вами устранили ошибку 0x80300024 при попытке установить Windows. Движемся дальше и сегодня пойдет речь, том, как выполнить чистую переустановку IIS роли. Для выполнения этой задачи у вас может быть ряд причин, например вы хотите начать работу с ролью IIS, так как будто вы ее только установили, вы можете захотеть попытаться устранить какие-то ошибки и проблемы. Давайте разбираться.

27.06.2021 IIS и FTP, web и seo 72 комментария

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз я вам рассказывал алгоритм действий, как я устранял черный экран в Windows 10 1903, я очень рад, что многим некоторые методы подошли и они все у себя починили. В сегодняшнем посте мы рассмотрим ситуацию, когда вам нужно скачать видео или ограниченное ограниченное с Гугл диска (Google Drive). Хоть в России, это не самый популярный облачный сервис по хранению данных, но все же ко мне периодически обращаются с этим вопросом, поэтому я и пишу данный пост.

23.12.2018 IIS и FTP, web и seo 4 комментария

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. Не так давно я вам рассказывал, о своем хостинге MChost, где вы могли бесплатно пользоваться его услугами в течении 3 месяцев, а так же рассматривали на нем услугу от Ddos-атак. В сегодняшней заметке я был хотел показать, как вы можете пополнить деньги на вашем счету с 3% бонусом, для дальнейшей оплаты услуг на Mchost.ru. Думаю, что такой небольшой четырехпроцентный бонус будет как никогда кстати.

10.11.2017 IIS и FTP, web и seo 1 Comment

Добрый день уважаемые подписчики и гости сайта Pyatilistnik.org, не так давно мы установили и настроили сайт на веб сервере IIS, время идет и в процессе эксплуатации могут появляться ошибки, так в моем случае я словил ошибку с кодом 1000 «Имя сбойного приложения: w3wp.exe 0xc0000374» или событие 1023 «Процесс был завершен из-за внутренней ошибки среды выполнения . NET по IP-адресу 746F74E0 (746E0000) с кодом выхода 80131506″, и не могу не включить сюда предупреждение WAS 5011 «Процесс, обслуживающий пул приложений «VIRT123_01», обнаружил неустранимую ошибку связи со службой активации Windows. Идентификатор процесса «7560». Поле данных содержит номер ошибки»

01.02.2020 IIS и FTP, web и seo No comments

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

IIS как пограничный веб-сервер (теперь haproxy) / Хабр

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

Дело в том, что мы используем IIS как прокси для других веб-серверов компании. Я расскажу, как это реализовано и с какими трудностями пришлось столкнуться.

Постановка задачи

Разберём на примере сервера YouTrack. Он представлен неприглядным srv-youtrack-01.local.domain и находится на веб-сервере внутри компании. Задача заключается в том, чтобы обеспечить доступ к нему из интернета по красивому имени yt.company.ru. При этом обязательно должен использоваться https.

Реализация

Для начала работы нам понадобится установить компонент URL Rewrite. Это можно сделать при помощи web platform installer, а также вручную. После его установки мы увидим в диспетчере служб IIS новый ярлык

переопределение URL-адресов».

При помощи этого инструмента можно создать правило переопределения адресов «обратный прокси-сервер».

При создании правила нужно указать URL сервера (без префикса http:// — его IIS добавит автоматически), на который будет происходить проксирование. В итоге мы получим правило, доступное для редактирования. Оно применяется не ко всем запросам, а только к тем, которые подходят под критерии, которые мы можем настраивать. Для начала проверяется URL на соответствие шаблону, после чего в ход идут проверки по другим критериям.

Сразу оговорюсь, что тут есть два пути: первый путь — создать набор правил с разными шаблонами URL-адресов для разных ресурсов на одном IIS-сайте; а второй — создать по сайту для каждого проксируемого ресурса и в каждом из них сделать по одному правилу. Понимая, что первый путь более джедайский, я все-таки избрал путь второй — пусть не такой красивый, зато я не рискую написав неправильное регулярное выражение для одного сайта сломать всю маршрутизацию. Поэтому шаблон URL-адреса у меня везде дефолтный «(.*)».

Итак, я создаю сайт yt.company.ru с биндингами на 80 и 443 порт и обязательным указанием имени узла, чтобы IIS знал, к какому сайту я обращаюсь. Про получение и установку сертификата для 443 позволю себе не упоминать. Обращу лишь внимание, что сам сервис настраивать на использование https не нужно — внутри сети шифроваться не от кого, а внешние запросы будут соединяться по ssl с пограничным сервером, который будет уже по незащищенному каналу проксировать запросы внутри сети.

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

Отлично, теперь все запросы yt.company.ru проксируются на внутренний сервер с неприглядным именем srv-youtrack-01.local.domain прозрачно для пользователя.

Однако, все запросы yt.company.ru отсекаются с ошибкой 403, что не очень красиво. Для решения этой проблемы можно либо создать index.html с редиректом, либо еще одно правило URL Rewrite, у которого в поле «действие» выберем постоянное перенаправление на нужный нам URL.

Следует обратить внимание, что правила для сайта применяются по порядку, поэтому сначала нужно расположить правило с условием, а потом правило без условий. При этом, так как второе правило применяется ко всем URL без исключения, для первого правила необходимо поставить (оставить поставленной) галочку «Остановить обработку последующих правил».

После манипуляций с графическим интерфейсом в корне нашего сайта создается web.config, который содержит все созданные правила. Поэтому если требуется проксировать еще какой-то сайт, то эти манипуляции повторять не нужно, можно просто скопировать web.config и изменить в нем требуемый URL или после копирования воспользоваться графическим интерфейсом для изменения правил. Более того, можно вообще не пользоваться интерфейсом, а писать сразу туда — кому как нравится.

Подводные камни

При переходе на вкладку «Agile boards» YouTrack генерит URL-адрес вида yt.company.ru/rest/agile/Overview-0/sprint/Iteration+24. Далее, при переключении между спринтами yt.company.ru/rest/agile/Overview-0/sprint/Iteration%252023?q=. При переходе на эти урлы IIS стал возвращать мне 404 ошибку. Это свидетельствовало о том, что запросы не проксируются. При этом переходы между сохраненными запросами вида yt.company.ru/issues/IT?q=%23{Current+work}+Assigned+to%3A+me+updated%3A+{This+week} вполне корректно отрабатывали.

Эксперименты с добавлением знака вопроса в середину проблемного URL закончились тем, что я стал получать 404 ошибку уже от YouTrack-сервера, а не IIS. Это натолкнуло меня на мысль, что IIS по каким-то своим соображениям (привет, Microsoft) интерпретирует URL и это надо исправить.

Проблема со знаком «плюс» в середине адреса решилась добавлением параметра requestFiltering allowDoubleEscaping=«true»:

<system.webServer>
    <security>
            <requestFiltering allowDoubleEscaping="true" />
    </security>
</system.webServer>

Но после этого все еще не работало переключение между спринтами. Выяснилось, что IIS считает такие запросы небезопасными. Эту проверку тоже пришлось отключить:

<system.web>
    <httpRuntime requestPathInvalidCharacters="" />
</system.web>

Вот какой web.config получился после всех манипуляций:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system. webServer>
        <rewrite>
            <rules>
                <rule name="ProxyToYouTrack" patternSyntax="ECMAScript" stopProcessing="true">
                    <match url="(.*)" negate="false" />
                    <action type="Rewrite" url="http://srv-youtrack-01.local.domain/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
                    <conditions>
                        <add input="{SERVER_PORT}" pattern="443" />
                    </conditions>
                </rule>
                <rule name="redir to ssl" enabled="true" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Redirect" url="https://yt.company.ru" />
                </rule>
            </rules>
            <outboundRules>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <security>
            <requestFiltering allowDoubleEscaping="true" />
        </security>
    </system. webServer>
    <system.web>
	<httpRuntime requestPathInvalidCharacters="" />
    </system.web>
</configuration>

Итоги

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

Таким образом у нас в организации проксируются абсолютно все веб-серверы, которым нужен доступ извне, среди которых есть и nginx, и apache, и svn, и gitlab, и exchange web access.

Основная проблема, которая заставляет меня находиться в поиске решения заключается в том, что через прокси не работает NTLM-авторизация, так нужная для многих сервисов компании Microsoft. Мёртвый продукт TMG использовать не хочется, поэтому сейчас пытаюсь разобраться с новой службой Windows Server 2012 R2 под названием Web Application Proxy параллельно поглядывая на nginx и apache, которые, кажется, тоже пока не умеют проксировать NTLM.

Ссылки

http://www.ifinity.com.au/Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path
stackoverflow.com/questions/2831142/asp-net-4-url-limitations-why-url-cannot-contain-any-3f-characters

Большой update:

В комментариях мне посоветовали попробовать haproxy. Зайдя на сайт я сделал поиск по странице «ntlm» и нашел «full HTTP keep-alive for better support of NTLM and improved efficiency in static farms», что придало мне уверенности.

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

Работает всё это дело достаточно просто и из коробки:

1. Устанавливается из backports при помощи apt-get (предпочитаю debian)

2. Пишется конфиг. Слегка правятся настройки проксируемых приложений

3. Переключается iptables на новый прокси

На втором пункте остановлюсь подробнее.

В секцию defaults конфига дописал

        mode    http
        balance roundrobin
        option redispatch
        http-send-name-header Host

Последний пункт нужен для того, чтобы бакенду передавалось имя хоста, остальные — «как у всех».

Далее создаются фронтенды для 80 и 443 портов, которые будут слушать и решать, на какой бакенд посылать запрос в зависимости от некоторых условий. А условие у меня только одно — пришедшее имя хоста.

frontend http
        bind *:80
        #Define hosts
        acl host_yt hdr(host) -i yt.company.name
        acl host_ar hdr(host) -i ar.company.name
        acl host_portal hdr(host) -i portal.company.name
        acl host_crm hdr(host) -i crm.company.name
        acl host_git hdr(host) -i git.company.name
        acl host_mail hdr(host) -i mail.company.name
        ...
        use_backend yt if host_yt
        use_backend ar if host_ar
        use_backend crm_r if host_crm
        use_backend git_r if host_git
        use_backend mail_r if host_mail

С https несколько сложнее. На помощь пришёл соседний топик, в комментариях которого рекомендовали использовать SNI. Его и использовал

frontend https
        bind *:443 ssl crt /etc/ssl/tfs.cer.ipk.pem crt /etc/ssl/yt.cer.ipk.pem crt /etc/ssl/crm.cer.ipk.pem crt /etc/ssl/git.cer.ipk.pem crt /etc/ssl/mail.cer.ipk.pem
        use_backend tfs if { ssl_fc_sni tfs.company.name }
        use_backend yt if { ssl_fc_sni yt.company.name }
        use_backend crm if { ssl_fc_sni crm.company.name }
        use_backend git if { ssl_fc_sni git.company.name }
        use_backend mail if { ssl_fc_sni mail.company.name }

Это оказалось очень просто! Первым делом генерируются сертификаты для всех бакендов — именно они и будут отдаваться клиентам. Я использую PKI от Микрософта, поэтому пришлось немного повозиться с генерацией реквестов, выдачей и передачей на прокси этих сертификатов. Допускается, кстати, использование *.company.name, но я решил что это как-то не очень солидно, тем более при таком малом количестве бакендов. После того, как сертификаты готовы, нужно написать их тупо в строчку как на примере выше, а дальше написать правила для бакендов — сертификаты будут подсовываться по порядку.

Конструкция с использованием sni настолько простая, что даже объяснять не надо. Правда, вышло так, что большинство почтовых клиентов андроида не умеют (или не хотят) sni, и шлют запросы на 443 порт без указания имени хоста. Не беда! Для таких случаев есть

 default_backend mail

(я, кстати, не проверил, какой сертификат подсовывается в этом случае)

Ну а дальше описываются бакенды. С http всё тривиально:

backend it
        server it.company.name srv-web-01
backend ar
        server ar.company.name srv-web-01

Здесь it.company.name — это имя хоста, которое будет передано на srv-web-01. Мне это нужно по тому, что IIS на этом сервере использует идентификацию по имени хоста.

Для https вот такие конструкции

backend yt
        server yt. company.name srv-youtrack-01:80
backend tfs
        server tfs.company.name tfs:443 ssl verify none

Тут можно разгрузить SSL, указав 80 порт — тогда шифроваться будет трафик между клиентом и проксей, а внутри сети не будет. А можно и дальше использовать https (verify none означает «не придираться к сертификату»). Стоит, однако, понимать, что клиент все-таки получает тот сертификат, который мы вписали при создании фронтенда. Если нужно подсовывать именно сертификат конечного сервера, то можнжо использовать способ, описанный в топике, который я указал выше.

Ещё один момент: хочется красиво редиректить http на https для некоторых серверов. Для этого я создал специальные бакенды с постфиксом _r, которые аккуратно перекидывают ничего не подозревающего пользователя на https.

backend tfs_r
        #redirect location https://tfs.company.name code 301
        redirect scheme https

Закомментированную строку не стал убирать сознательно — изначально использовался такой вариант, но он перенаправлял меня в корень сайта, что очень неудобно, если пользователь нажал на длинную ссылку http ://site. company.name/lib/doc/Русские%20буквы%20в%20названии.docx, а его перекинуло на главную страницу без всякой надежды найти свой документ. Велика вероятность, что он закроет её и попробует пройти по ссылке снова, но опять ничего не получит и очень расстроится. Чтобы такого не произошло, нам помогает конструкция redirect scheme https, которая аккуратно перенаправляет пользователя, подставляя весь URL.

Подробно обо всех тонкостях конфигурирования на странице документации cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2

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

Включение IIS и необходимых компонентов IIS в Windows Server 2012/2012 R2 — руководства по установке

Перейти к содержимому
ArcGIS Enterprise

Войти

Поиск 10.5 Руководства по установке

ОбзорEnterpriseServerPortalWeb AdaptorData StoreПодробнее…

В начало

В этом разделе

Необходимые компоненты IIS

Для ArcGIS Web Adaptor требуется, чтобы IIS был включен, а определенные компоненты IIS были включены в Windows Server 2012/2012 R2. Установка не будет продолжена, если службы IIS не обнаружены и определенные компоненты IIS не включены.

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

Чтобы узнать, как включить IIS и необходимые компоненты IIS в Windows Server 2012/2012 R2, см. приведенные ниже инструкции.

Откройте Диспетчер серверов и щелкните Управление > Добавить роли и компоненты. Нажмите «Далее.
Выберите Установка на основе ролей или компонентов и нажмите кнопку Далее.
Выберите соответствующий сервер. По умолчанию выбран локальный сервер. Нажмите «Далее.
Включите веб-сервер (IIS) и нажмите кнопку Далее.
Для установки веб-адаптера не требуются дополнительные функции, поэтому нажмите «Далее».
В диалоговом окне Роль веб-сервера (IIS) нажмите кнопку Далее.
В диалоговом окне Выбор служб ролей убедитесь, что перечисленные ниже компоненты веб-сервера включены. Нажмите «Далее.
Проверьте правильность настроек и нажмите «Установить».
После завершения установки щелкните Закрыть, чтобы выйти из мастера.

Перечисленные ниже компоненты IIS удовлетворяют минимальным требованиям для запуска Web Adaptor. Если другие компоненты IIS включены, их не нужно удалять.

Веб-сервер
- Общие функции HTTP
  - Документ по умолчанию
  - Статическое содержимое
- Безопасность
  - Фильтрация запросов
  - Базовая аутентификация
  - Аутентификация Windows
- Разработка приложений
  - Расширяемость . NET 4.5
  - Расширяемость .NET
  - ASP.NET 4.5
  - ASP.NET
  - Расширения ISAPI
  - Фильтры ISAPI
Средства управления
- Консоль управления IIS
- Совместимость управления IIS 6
  - Совместимость метабазы IIS 6
- Сценарии и инструменты управления IIS
- Служба управления

Отзыв по этой теме?

В этом разделе

Необходимые компоненты IIS

Как установить сертификаты в Microsoft IIS 8.x

В этой статье подробно рассказывается, как установить сертификаты в Microsoft IIS 8.x.

Откройте ZIP-файл, содержащий ваш сертификат. Сохраните файл с именем your_domain_name.cer на рабочий стол защищаемого веб-сервера.
На начальном экране щелкните или найдите Internet Information Services (IIS) Manager и откройте его.
Нажмите на имя сервера.
В центральном меню дважды нажмите кнопку « Сертификаты сервера » в разделе «IIS» (она находится в середине меню).
В меню «Действия» (справа) нажмите « Завершить запрос сертификата… ». Откроется мастер завершения запроса сертификата.
Перейдите к предоставленному вам файлу your_domain_name.cer. Затем вам будет необходимо ввести понятное имя. Понятное имя не является частью самого сертификата, но используется администратором сервера, чтобы легко отличить сертификат. Выберите размещение нового сертификата в Личное хранилище сертификатов .
При нажатии «ОК» сертификат будет установлен на сервер.
После успешной установки SSL-сертификата на сервер вам потребуется назначить этот сертификат соответствующему веб-сайту с помощью IIS.
В меню «Подключения» главного окна диспетчера информационных служб Интернета (IIS) выберите имя сервера, на который был установлен сертификат.
В разделе «Сайты» выберите сайт, который необходимо защитить с помощью SSL.
В меню «Действия» (справа) нажмите « Привязки… ». Откроется окно «Привязки сайта».
В окне «Привязки сайта» нажмите « Добавить… ». Откроется окно «Добавить привязку сайта».
В разделе «Тип» выберите https . IP-адрес должен быть IP-адресом сайта или All Unassigned, а порт, через который трафик будет защищен SSL, обычно равен 443. В поле «Сертификат SSL» должен быть указан сертификат, который был установлен на шаге 7.
Нажмите «ОК».
Теперь ваш SSL-сертификат установлен, а веб-сайт настроен на прием безопасных соединений.

Как установить и настроить SSL-сертификат в Windows Server 2012 — IIS 8 и Windows Server 2012 R2 — IIS 8. 5 (несколько сертификатов с использованием SNI)

Откройте ZIP-файл, содержащий ваш сертификат. Сохраните файл с именем your_domain_name.cer на рабочий стол защищаемого веб-сервера.
На начальном экране нажмите или найдите Диспетчер информационных служб Интернета (IIS) и откройте его.
Нажмите на имя сервера.
В центральном меню дважды нажмите кнопку « Сертификаты сервера » в разделе «IIS» (она находится в середине меню).
В меню «Действия» (справа) нажмите « Завершить запрос сертификата… ». Откроется мастер завершения запроса сертификата.
Перейдите к предоставленному вам файлу your_domain_name.cer. Затем вам будет необходимо ввести понятное имя. Понятное имя не является частью самого сертификата, но используется администратором сервера, чтобы легко отличить сертификат. Выберите размещение нового сертификата в Личное хранилище сертификатов .
При нажатии «ОК» сертификат будет установлен на сервер.
Примечание: Существует известная проблема в IIS 8, приводящая к следующей ошибке: «Не удалось удалить сертификат». Если это тот же сервер, на котором вы создали CSR, то в большинстве случаев сертификат действительно установлен. Просто закройте диалоговое окно и нажмите «F5», чтобы обновить список сертификатов сервера. Если новый сертификат теперь находится в списке, значит, он был установлен на сервер, но вы можете проверить и убедиться, что сертификат находится в хранилище сертификатов веб-хостинга. Если его нет в списке, вам нужно будет перевыпустить сертификат, используя новый CSR. После создания нового CSR войдите в свою учетную запись и нажмите кнопку замены для своего сертификата.
После успешной установки SSL-сертификата на сервер вам потребуется назначить этот сертификат соответствующему веб-сайту с помощью IIS.
В меню «Подключения» главного окна диспетчера информационных служб Интернета (IIS) выберите имя сервера, на который был установлен сертификат.
В разделе «Сайты» выберите сайт, который необходимо защитить с помощью SSL.
В меню «Действия» (справа) нажмите « Привязки… ». Откроется окно «Привязки сайта».
В окне «Привязки сайта» нажмите « Добавить… ». Откроется окно «Добавить привязку сайта».
В разделе «Тип» выберите https . IP-адрес должен быть IP-адресом сайта или Все неназначенные, а порт, через который трафик будет защищен SSL, обычно равен 443. В поле «Сертификат SSL» должен быть указан сертификат, который был установлен на шаге 7.
Нажмите «ХОРОШО.»
Ваш первый SSL-сертификат установлен, а веб-сайт настроен на прием безопасных соединений.
Повторите шаги для создания CSR для вашего 2+ сайта.
Установите файл сертификата, как указано выше, вплоть до шага 12.
В разделе «Тип» выберите https . IP-адрес должен быть IP-адресом сайта или All Unassigned, а порт, через который трафик будет защищен с помощью SSL, обычно равен 443.