Ipsec vs tls/srtp в обеспечении безопасности voip / хабр

▏Где искать следы подключения по RDP▕

Логи. В первую очередь следует немедленно проверить логи событий:
%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
Событие 1149 для успешного подключения до аутентификации с использованием логина и пароля, но после аутентификации IP-адреса источника подключения

Важно искать подключения с необычных IP-адресов, сюда же может попасть перебор паролей.

%SystemRoot%\System32\Winevt\Logs\Security.evtx
Событие 4624 — для успешного входа, 4625 — для неудачного входа, 4778 — для переподключения, 4634 — для отключения
Стоит обратить внимание на «LogonType». Для удаленных подключений оно будет равно 3, 10 или 7
Здесь необходимо искать успешные события входа с необычных IP-адресов, обращать внимание на неуспешные события входа — это может быть атака перебором.

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
События 21, 22 и 25 — для успешного входа или переподключения, 23 — для отключения

Следует искать события с необычных IP-адресов.

Нередко злоумышленники чистят логи. При этом чаще всего чистят только Security.evtx, чуть реже — Security.evtx и Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx сразу. По этой причине крайне желательно просматривать все три лога, а лучше заранее настроить перенаправление событий в SIEM-систему.

Сессии легитимных пользователей. Практически всегда злоумышленники, которые занимаются распространением шифровальщиков, начинают изучение внутренней сети своей жертвы почти сразу после проникновения. Иногда им удается переподключиться к уже имеющимся сессиям RDP-серверов, доступных из внутренней сети. Это может произойти, когда подключение легитимного пользователя уже установлено, но на уровне TCP оно разорвано (например, было закрыто окно RDP). В этом случае при повторном подключении сессия восстанавливается и злоумышленник входит на сервер. Это означает, что в логе можно увидеть, что подключение инициировано легитимным пользователем в день X, а в день X+N с той же машины уже переподключится атакующий. Поэтому следует смотреть не только на события установки подключений, но и на события переподключений и отключений.

Если следы обнаружены

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

Включаем NLA – Network Level Authentication

Функция NLA появляется в NT 6.0, а позже добавляется возможность её частичного использования в предыдущей версии ОС путём установки SP3 для XP.Суть данной функции достаточно проста. В версиях RDP до 6.0 при подключении по RDP клиенту до аутентификации надо показать окно входа – т.е. вначале показать, а потом уже он попробует зайти в систему. Это создаёт простую уязвимость – сервер можно перегрузить пачкой запросов “а дай-ка мне попробовать новую сессию начать”, и он будет вынужден на все запросы отвечать созданием сессии и ожиданием входа пользователя. Фактически, это возможность DoS. Как с этим можно бороться? Логично, что надо придумать схему, целью которой будет как можно раньше запросить у клиента учётные данные. Оптимально – чтобы было что-то типа как kerberos в домене. Это и было сделано. NLA решает две задачи:

Клиент аутентифицируется до инициации терминальной сессии.
Появляется возможность передать данные локального клиентского SSP на сервер, т.е. начинает работать Single Sign-On.

Реализуется это через новый провайдер безопасности – CredSSP. Почитать его техническую спецификацию можнотут, ну, а говоря проще, надо всегда включать данную функцию. Конечно, учитывая, что для её работы нужно, чтобы:

Клиентская ОС (та, с которой идёт подключение) была Windows XP SP3 и выше.
Серверная ОС (та, к которой будет подключение) была Windows Server 2008 и выше.

Как включается NLA со стороны RDP-сервера

Лучше всего включить NLA на всех серверах через групповую политику. Для этого надо зайти в целевой объект групповой политики и там последовательно выбрать “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Remote Desktop Session Host” -> “Security” и там включить параметр Require user authentication for remote connections by using Network Layer Authentication.

Можно включить и локально. Это делается путём вызова подменю Properties (стандартное подменю у Computer) и выбора там вкладки Remote, в которой будет выбор из трёх вариантов – запрещать подключения по RDP к данному хосту, разрешать подключения по любому RDP, разрешать только с NLA. Всегда включайте вариант с NLA, это в первую очередь защищает сервер.

NLA и Windows XP

В случае, если у Вас Windows XP, то Вы также можете воспользоваться данной функцией. Распространённое утверждение “Для NLA нужна как минимум виста, это Microsoft сделал чтобы апгрейдились” ложно. В Service Pack 3 добавляется реализация CredSSP, позволяющая делегировать клиентские credentials’ы, которыми обладает местный SSP, на сервер. Т.е., говоря проще, это специально сделано, чтобы с Windows XP можно было подключаться на системы с NT 6.0+. На саму Windows XP SP3 с данной функцией подключаться не получится, поддержка NLA будет частичной (поэтому RDP сервер с поддержкой подключения клиентов с использованием NLA из Windows XP сделать штатными способами не получится, Windows XP будет только NLA-совместимым клиентом).

Включать данный функционал нужно в явном виде, так как несмотря на то, что Service Pack 3 добавляет приносит новую dll криптопровайдера, он её не включает.

Как включить CredSSP в XP

Ещё раз – данная операция проводится строго после установки Service Pack 3 на Windows XP и в контексте нашего разговора нужна для того, чтобы было возможно подключение к другим серверам по RDP 6.1 с использованием NLA.

Шаг первый – расширяем перечень Security Packages.Для этого мы откроем ключ реестра

и найдём в нём значение . Нажмём правую кнопку и выберем “Modify” (не Modify Binary Data, а просто Modify). Там будет список вида “название package на каждой строке”. Нам надо добавить туда . Остальное надо оставить. Место добавления некритично.

Второй шаг – подцепляем библиотеку.Ключ будет другим:

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

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

Настройка службы шлюза служб терминалов

Служба «Шлюз TS (служб удаленных рабочих столов)» Windows Server 2016 разрешает сторонним пользователям реализовывать удаленное подключение к терминальным серверам и другим машинам частной сети с активированным протоколом удаленного рабочего стола. Служба обеспечивает RDP безопасность подключений за счет использования протокола HTTPS/SSL, что позволяет не заниматься настройкой VPN для шифрования трафика.

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

Порядок действий для установки службы «Шлюз ТS»:

Откройте Диспетчер серверов и на главной его странице нажмите ссылку Добавить роли и компоненты
Нажмите Далее, а затем выберите Установка ролей или компонентов.
Выберите ваш сервер из пула серверов
Выберите Службы удаленных рабочих столов и нажмите Далее несколько раз, пока не достигнете страницы Выбор служб ролей
Выберите службы ролей Шлюз удаленных рабочих столов (рис. 7)
Нажмите кнопку Добавить компоненты
Нажимайте Далее для завершения процедуры установки. Когда все будет готово для установки выбранных компонентов, нажмите кнопку Установить (рис. 8).

Рис. 7. Установка службы ролей

Рис. 8. Все готово для установки

Далее нужно создать сертификат для шлюза служб удаленных рабочих столов. Запустите Диспетчер служб IIS, выберите пункт Сертификаты сервера. На панели справа выберите Создать сертификат домена. Введите необходимые сведения (рис. 11).

Рис. 9. Диспетчер служб IIS

Рис. 10. Выберите Создать сертификат домена

Рис. 11. Информация о сертификате

Далее нужно выбрать центр сертификации, который подпишет сертификат, и нажать кнопку Готово. Сертификат появится в списке сертификатов.

Следующий шаг — настройка шлюза TS на использование сертификата. Вернитесь к Диспетчеру серверов и, используя меню Средства, запустите Диспетчер шлюза удаленных рабочих столов

Обратите внимание, что есть одна ошибка — Сертификат сервера еще не установлен или не выбран. Собственно, все, что остается сделать — нажать ссылку рядом Просмотр и изменение свойств сертификата и выбрать ранее созданный сертификат, нажав кнопку Импорт сертификата (рис. 13)

В этом окне также можно создать самозаверяющийся сертификат.

Рис. 12. Диспетчер шлюза удаленных рабочих столов

Рис. 13. Выбор сертификата SSL

Выбираем правильный сертификат для RDP

Если у Вас есть возможность пользоваться не-дефолтным сертификатом для RDP, то лучше пользоваться именно им. Это не повлияет на безопасность сессии как таковой, но повлияет на безопасность и удобство подключения. В сертификате, который оптимально использовать, должны быть следующие момент:

Имя (в subject или SAN), посимвольно совпадающее с тем именем, которое вводит клиент, подключающийся к серверу.
Нормальное расширение CDP, указывающее на рабочий CRL (желательно хотя бы на два – OCSP и статический).
Желательный размер ключа – 2048 бит. Можно и больше, но помните об ограничениях CAPI2 в XP/2003.
Не экспериментируйте с алгоритмами подписи/хэширования, если Вам нужны подключения со стороны XP/2003. Чуть больше информации про это в статье про настройку TLS, но вкратце – выберите SHA-1, этого вполне достаточно.

Чуть подробнее остановлюсь на выпуске специального сертификата для RDP-сервера.

Делаем всё красиво – специальный шаблон сертификата для RDP-серверов

Идеально будет, если сертификат для RDP сделать не на основе обычного шаблона (типа Web Server) и иметь в поле (которое в сертификате будет более привычно называться Enchanced Key Usage – EKU) стандартные значения и , а добавить свой шаблон, в котором будет единственное, специальное, не добавляемое стандартными способами значение применения – . Это значение Application Policy придётся создать вручную, его OID’ом будет, ну а после – уже можно сделать новый шаблон сертификата, на основании которого и выпустить сертификат, адресно “заточеный” под RDP Server.

Чтобы полностью автоматизировать эту операцию, сделайте у нового шаблона предсказуемое название – например, “RDPServerCert” – и зайдите в объект групповой политики, а там откройте Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Выберите параметр и включите его, а в поле значения введите название – мы сделали RDPServerCert. Теперь все доменные хосты, подпадающие под эту политику, будут в случае включения на них RDP сами идти к Certification Authority, запрашивать в случае отсутствия себе сертификат на основе указанного шаблона, и автоматически делать его дефолтным для защиты подключений по RDP. Просто, удобно, эффективно.

Как перенести сайт с HTTP на HTTPS правильно

Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил и версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в нужный адрес в директиве Hosts.

Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.

Вот, скажем, пример файла для сайта

User-agent: Yandex
Disallow:
Host: https://sheensay.ru

User-agent: *
Disallow:

Sitemap: https://sheensay.ru/sitemap.xml

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола . У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы заменяются на абсолютные или относительные .
Приведу пример:

НЕПРАВИЛЬНО:
ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

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

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

О дивный новый мир

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

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

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

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

Standard RDP Security

При данном подходе аутентификация, шифрование и обеспечение целостности реализуется средствами, заложенными в RDP- протокол.

Аутентификация

Аутентификация сервера выполняется следующим образом:

При старте системы генерируется пара RSA- ключей
Создается сертификат (Proprietary Certificate) открытого ключа
Сертификат подписывается RSA- ключом, зашитым в операционную систему (любой RDP -клиент содержит открытый ключ данного встроенного RSA- ключа).
Клиент подключается к серверу терминалов и получает Proprietary Certificate
Клиент проверяет сертификат и получает открытый ключ сервера (данный ключ используется в дальнейшем для согласования параметров шифрования)

Аутентификация клиента проводится при вводе имени пользователя и пароля.

Шифрование

В качестве алгоритма шифрования выбран потоковый шифр RC4. В зависимости от версии операционной системы доступны различные длины ключа от 40 до 168 бит.

Максимальная длина ключа для операционных систем Winodws:

Windows 2000 Server — 56 бит
Windows XP, Windows 2003 Server — 128 бит
Windows Vista, Windows 2008 Server — 168 бит

При установке соединения после согласования длины генерируется два различных ключа: для шифрования данных от клиента и от сервера.

Целостность

Целостность сообщения достигается применением алгоритма генерации MAC (Message Authentication Code) на базе алгоритмов MD5 и SHA1.

Начиная с Windows 2003 Server, для обеспечения совместимости с требованиями стандарта FIPS (Federal Information Processing Standard) 140-1 возможно использование алгоритма 3DES для шифрования сообщений и алгоритма генерации MAC, использующего только SHA1, для обеспечения целостности.

Защита от буртфорса

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

Для блокировки атакующих IP адресов будем использовать свободно распратраняющееся ПО — IPBan. Это приложение проверено и работает в Windows Server 2008 и всех последующие версях. Windows XP и Server 2003 — не роддерживаются. Алгоритм его работы простой: программа мониторит журнал событий Windows, фиксирует неудачные попытки входа в систему и, после 5-ти попыток злоумышленника подобрать пароль, блокирует IP адрес на 24 часа.

Итак:

Cкачайте архив с программой здесь;
В нем находятся два архива IPBan-Linux-x64.zip
и IPBan-Windows-x86.zip,
нам нужен последний. Распакуйте архив IPBan-Windows-x86.zip
в любое удобное место (в примере это корень диска C:
);
Так как файлы скачанные с интернета система автоматически блокирует в целях безопасности, для работы приложения необходимо разблокировать все файлы. Щелкните правой кнопкой мыши на все извлеченные файлы и выберите свойства. Обязательно выберите «разблокировать», если этот параметр доступен. Либо, откройте окно PowerShell (Win + R,
введитеpowershell
и «ОК»)
и воспользуйтесь командой следующего вида:

Например:

4. Вам нужно внести следующие изменения в локальную политику безопасности, чтобы убедиться, что в логах системы отображаются IP-адреса. Октройте «Локальную политику безопасности» (Win + R,
введите secpol.msc
и «OK
«). Перейдите в «Локальные политики» —> «Политика аудита» и включить регистрацию сбоев для «Аудита входа в систему» и «Аудита событий входа в систему»:

5. Для Windows Server 2008 или эквивалентного вам следует отключить логины NTLM и разрешить только NTLM2-вход в систему. В Windows Server 2008 нет другого способа получить IP-адрес для входа в систему NTLM. Октройте «Локальную политику безопасности» (Win + R,
введите secpol.msc
и «OK
«). Перейдите в «Локальные политики» —> «Параметры безопасности» —> «Сетевая безопасность: Ограничения NTLM: входящий трафик NTLM» и установите значение «Запретить все учетные записи»:

6. Теперь необходимо создать службу IPBan, чтобы приложение запускалось при старте системы и работало в фоновом режиме. Запустите оснастку PowerShell (Win + R,
введитеpowershell
и «ОК»)
и выпоните команду типа:

Например:

Перейдите в службы (Win + R,
введите services.msc
и «OK
«) и з
апустите службу IPBAN
, в дальнейшем она будет запускаться автоматически:

В «Диспетчере задач» можно убедиться, что служба запущена и работает:

Таким образом, программа следит за неудачными попытками авторизации и добавляет неугодные IP адреса в созданное правило для входящих подключений брандмауэра Windows:

Заблокированные IP адреса можно разблокировать вручную. Перейдите на вкладку «Область» в свойствах правила «IPBan_0» и удалите из списка нужный Вам IP адрес:

Параметры отображения

Отображаемое имя	Свойство RDP	Описание	Значения	Значение по умолчанию
Многообразные дисплеи	использовать multimon:i:value	Определяет, будет ли удаленный сеанс использовать один или несколько дисплеев локального компьютера.	— 0: не включайте поддержку нескольких дисплеев.- 1: включите поддержку нескольких дисплеев.
Выбранные мониторы	selectedmonitors:s:value	Указывает, какие локальные дисплеи нужно использовать из удаленного сеанса. Выбранные дисплеи должны быть непрерывными. Требуется задать значение 1.Доступно только на клиентах Windows Inbox (MSTSC) и Windows Desktop (MSRDC).	Разделенный запятыми список идентификаторов дисплеев для определенного компьютера. Вы можете получить идентификаторы, вызвав . Первый идентификатор в списке будет установлен в качестве основного дисплея для сеанса.	Все дисплеи.
Развернуть до текущих дисплеев	maximizetocurrentdisplays:i:value	Определяет, на каком дисплее удаленный сеанс откроется в полноэкранном режиме при развертывании. Требуется задать значение 1.Доступно только на клиенте Windows Desktop (MSRDC).	— 0: сеанс выполняется в полноэкранном режиме на дисплеях, изначально выбранных при максимизации.— 1. Сеанс динамически переходит в полноэкранный режим на дисплеях, затронутых окном сеанса при максимизации.
Переключение с несколькими на один дисплей	singlemoninwindowedmode:i:value	Определяет, будет ли удаленный сеанс с несколькими дисплеями автоматически переключаться на один дисплей при выходе из полноэкранного режима. Требуется задать значение 1.Доступно только на клиенте Windows Desktop (MSRDC).	— 0: сеанс сохраняет все дисплеи при выходе из полноэкранного режима.- 1: сеанс переключается на один дисплей при выходе из полноэкранного режима.
Режим экрана	экранный режим id:i:value	Определяет, будет ли отображаться окно удаленного сеанса на весь экран при запуске подключения.	— 1: удаленный сеанс появится в окне.- 2: удаленный сеанс будет отображаться в полноэкранном режиме.	2
Интеллектуальное изменение размера	smart sizing:i:value	Определяет, будет ли масштабироваться на локальном компьютере содержимое удаленного сеанса в соответствии с размером окна.	— 0: содержимое локального окна не масштабируется при изменении размера.- 1: содержимое локального окна будет масштабироваться при изменении размера.
Динамическое разрешение	динамическое разрешение:i:value	Определяет, будет ли автоматически обновляться разрешение удаленного сеанса при изменении размера локального окна.	— 0: разрешение сеанса остается статическим во время сеанса.- 1: разрешение сеанса обновляется по мере изменения размера локального окна.	1
Размер рабочего стола	идентификатор размера рабочего стола:i:value	Задает размеры удаленного рабочего стола сеанса из набора предопределенных параметров. Этот параметр переопределяется, если указаны и .	— 0: 640×480- 1: 800×600.- 2: 1024×768.- 3: 1280×1024.- 4: 1600×1200.	Соответствует локальному компьютеру.
Высота рабочего стола	desktopheight:i:value	Задает высоту разрешения удаленного сеанса в пикселях.	Числовое значение от 200 до 8192.	Соответствует локальному компьютеру.
Ширина рабочего стола	desktopwidth:i:value	Задает ширину разрешения удаленного сеанса в пикселях.	Числовое значение от 200 до 8192.	Соответствует локальному компьютеру.
Коэффициент масштабирования рабочего стола	desktopscalefactor:i:value	Указывает коэффициент масштабирования удаленного сеанса, чтобы увеличить размер содержимого на дисплее.	Числовое значение из следующего списка:- 100- 125- 150- 175- 200- 250- 300- 400- 500.	Соответствует локальному компьютеру.

Сценарии поддержки подключений к удаленному рабочему столу и службы технической поддержки

В сценариях поддержки службы поддержки, в которых персоналу требуется административный доступ для предоставления удаленной помощи пользователям компьютеров через сеансы удаленного рабочего стола, Майкрософт рекомендует не использовать Защитник Windows Remote Credential Guard в этом контексте. Это связано с тем, что если сеанс RDP инициируется в скомпрометированном клиенте, который уже контролируется злоумышленником, он может использовать этот открытый канал для создания сеансов от имени пользователя (без ущерба для учетных данных) для доступа к каким-либо из ресурсов пользователя в течение ограниченного времени (несколько часов) после отключения сеанса.

Поэтому вместо этого рекомендуется использовать параметр Режим ограниченного Администратор. Для сценариев поддержки службы поддержки подключения по протоколу RDP следует инициировать только с помощью параметра /RestrictedAdmin. Это помогает гарантировать, что учетные данные и другие пользовательские ресурсы не будут доступны скомпрометируемым удаленным узлам. Дополнительные сведения см. в разделе Устранение проблем с передачей хэша и других кражи учетных данных версии 2.

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

Дополнительные сведения о LAPS см. в 3062591 рекомендаций по безопасности Майкрософт.

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это ):

cert.pem — это сертификат SSL/TLS;
key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям . И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта , мы можем использовать следующую конфигурацию ( заменяем на свой домен, — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}