Создание шаблона сертификата RDP в ADCS
Первый шаг состоит в создании шаблона сертификата, с помощью которого Windows клиенты будут автоматически генерировать сертификаты используемые в RDP подключениях. Для этого в оснастке ADCS переходим к управлению шаблонами сертификатов:
Открытие оснастки управления шаблонами ADCS
Дублируем сертификат Computer
Дублирование шаблона компьютера
Задаем имя будущего шаблона:
Задание имени шаблона RDP
Указываем настройки совместимости:
Настройка совместимости шаблона сертификата RDP
В Extensions, необходимо задать правильные Application Policies для поддержки TLS в RDP протоколе
Редактирование расширений шаблона сертификата RDP
Для этого удаляем Client Authentication и Server Authentication и добавляем Remote Desktop Authentication с OID 1.3.6.1.4.1.311.54.1.2, как показано на скриншоте:
Создание Application Policy для сертификата RDP
Далее, необходимо задать группу безопасности, члены которой должны автоматически сгенерировать сертификат по этому шаблону. Для этого добавляем нужную группу безопасности в DACL и назначаем соответствующие права:
Настройки безопасности шаблона сертификата RDP
Завершающим шагом будет его выпуск на выдающем корпоративном ЦС:
Выпуск сертификата RDP
Использование не microsoft Enterprise сертификатов
Если используется инфраструктура общедоступных ключей, использующая не службы Майкрософт, шаблоны сертификатов, опубликованные в локальном Active Directory, могут быть недоступны. Инструкции по интеграции Intune/SCEP с развертываниями PKI, не относящейся к Microsoft, см. в ссылке Использование сторонних органов сертификации (CA)с SCEP в Microsoft Intune .
В качестве альтернативы использованию SCEP или если ни одно из ранее охваченных решений не будет работать в вашей среде, вы можете вручную создавать запросы на подписание сертификатов (CSR) для отправки в свой PKI. Для оказания помощи в этом подходе можно использовать командлет Generate-CertificateRequest PowerShell.
Командный Generate-CertificateRequest создает файл .inf для уже существующего Windows Hello для бизнеса. .inf можно использовать для создания запроса сертификата вручную с помощью certreq.exe. Командлет также создает файл .req, который может быть отправлен в ваш PKI для сертификата.
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:
Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Подключение к серверу терминалов через шлюз
Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.
Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:
* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.
Переходим на вкладку Дополнительно и кликаем по Параметры:
Переключаем параметр приложения в положение Использовать следующие параметры сервера шлюза удаленных рабочих столов и указываем внешнее имя сервера:
* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример)
Кликаем Подключить:
Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:
Переходим на вкладку Состав и кликаем Копировать в файл:
Указываем путь для выгрузки файла:
Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:
Выбираем Локальный компьютер — Далее:
В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:
Импортируем сертификат.
После снова пробуем подключиться к удаленному рабочему столу через шлюз:
Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).
Возможные ошибки
При подключении мы можем столкнуть со следующими ошибками.
1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.
Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.
2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).
Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке .
3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.
В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
How to Deploy RDP SSL/TLS Certificates using Group Policy?
Now you need to configure a domain GPO to automatically assign RDP certificates to computers/servers according to the configured template.
It is supposed that all domain computers trust the corporate Certificate Authority, i.e. the root certificate has been added to the Trusted Root Certificate Authorities using GPO.
- Open the Domain Group Policy Management console (gpmc.msc), create a new GPO object and link it to the OU containing RDP/RDS servers or computers to automatically issue TLS certificates to secure RDP connections;
- Go to the following GPO section Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Enable the Server Authentication Certificate Template policy. Specify the name of the CA template you have created earlier (RDPTemplate);
- Then in the same GPO section, enable the Require use of specific security layer for remote (RDP) connections policy and set the value SSL for it;
- To automatically renew an RDP certificate, go to the Computer configuration -> Windows settings -> Security Settings -> Public Key Policies section of the GPO and enable the Certificate Services Client – Auto-Enrollment Properties policy. Check the “Renew expired certificates, update pending certificates and remove revoked certificates” and “Update certificates that use certificate templates” options;
- If you want your clients to always verify the RDP server certificate, you must configure the Configure Authentication for Client = Warn me if authentication fails policy (Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
- If needed, open the incoming RDP Port TCP/UDP 3389 using firewall policies;
- Then update group policy settings on the client computer, launch the computer certificate console () and make sure that the Remote Desktop Authentication certificate issued by your CA has appeared in the Personal -> Certificates section.
If the new Group Policy settings have not been applied, use the gpresult tool and this article to diagnose.
To apply the new RDP certificate, restart Remote Desktop Services:
After that, when connecting to a server using RDP, you won’t see a request to confirm that the certificate is trusted (to see the request, connect to the server the certificate is issued for using its IP address instead of the FQDN). Click View certificate, go to the Details tab and copy the value in the Thumbprint field.
In the Issued Certificates section of the Certification Authority console, you can make sure that an RDPTemplate certificate has been issued for the specific Windows server/computer. Also check the certificate Thumbprint value:
Then compare this thumbprint with the certificate thumbprint used by the Remote Desktop Service. You can view the value of the RDS certificate thumbprint in the registry (HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations, the TemplateCertificate parameter) or using the following PowerShell command:
Then, when connecting to the remote desktop of any Windows host, you won’t see a warning of an untrusted RDP certificate.
Принцип работы
RDPl основан на протоколе TCP. Порядок его работы в общих чертах выглядит так:
- Устанавливается соединение на транспортном узле.
- Происходит инициализация сессии, определяется порядок передачи данных.
- Сервер начинает передавать клиенту графический вывод. В ответ он ожидает, что пользователь введет входные данные.
Приоритетный способ — передача вывода графическими примитивами: прямоугольниками, линиями, текстами, эллипсами и так далее. Это позволяет экономить трафик. Если договориться о параметрах передачи примитивов не удалось, то клиенту передается изображение графического экрана.
RDP-клиент обрабатывает команды от сервера терминалов и использует собственную графическую подсистему для для вывода изображения. Пользовательский ввод передается благодаря скан-кодам. Сигналы нажатий и отпусканий кнопок передаются отдельно с помощью специального флага.
Remote Desktop Protocol поддерживает несколько виртуальных каналов внутри одной сессии. Это дает доступ к дополнительным возможностям для управления. Можно использовать принтер или порты, перенаправлять файловую систему, работать с единым буфером, использовать подсистему аудио для передачи звука.
Настройка срока действия маркера TLS в НПСС
Эта процедура используется для изменения времени, в течение которого НПСС кэширует обработчик TLS клиентских компьютеров. После успешной проверки подлинности клиента доступа свойства подключения TLS для клиентского компьютера НПСС кэшируются как обработчик TLS. Продолжительность по умолчанию для маркера TLS составляет 10 часов ( 36 000 000 миллисекунд ) . Вы можете увеличить или уменьшить время окончания срока действия маркера TLS, выполнив следующую процедуру.
Членство в группах « Администраторы» или «эквивалентное» является минимальным требованием для выполнения этой процедуры.
Важно!
Эта процедура должна выполняться на сервере политики сети, а не на клиентском компьютере.
Настройка срока действия маркера TLS в НПСС
-
На сервере политики сети откройте редактор реестра.
-
Перейдите к разделу реестра hKey _ Local _ мачине\систем\куррентконтролсет\контрол\секуритипровидерс\счаннел
-
В меню Правка выберите пункт создать, а затем нажмите клавишу.
-
Введите серверкачетиме и нажмите клавишу ВВОД.
-
Щелкните правой кнопкой мыши серверкачетиме, выберите пункт создать, а затем выберите значение DWORD (32-бит).
-
Введите время в миллисекундах, в течение которого НПСС должен кэшировать маркер TLS клиентского компьютера после первой успешной попытки проверки подлинности клиента.
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.
Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:
rdpsign. exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 «C:\Users\root\Desktop\rdp. rdp»
Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).
Предыдущая статья Следующая статья
WindowsServer
Импортировать сертификат сервера
- Импорт,иВсе должны быть импортированы вСправочник. PS: «Автоматически выбирать хранилище сертификатов в соответствии с типом сертификата» также допустимо, оно будет выбрано по умолчаниюкаталог
Установить сертификат удаленного рабочего стола
Используйте команды Откройте диспетчер сертификатов и разверните->, Дважды щелкните сертификат, который мы только что импортировали, выберитеИ найти, Скопируйте его содержимое в блокнот (или командную строку), удалитеЗапасной. PS: первая строка шестнадцатеричных пробелов скрыта.
Используйте команду
Появляется слово «успешное обновление», в случае неудачи внимательно проверьте детали.
Изменить групповую политику
Опять же, OCSP, используемый запросом отзыва сертификатов по умолчанию, но автор до сих пор не настроен, может только принудительно вызвать CRL, изменив групповую политику. Статус отзыва сертификата, этого шага можно избежать! Пожалуйста, свяжитесь с автором к тому времени! Спасибо
->, На этом этапе настройка на стороне сервера завершена.
Смена стандартного порта Remote Desktop Protocol
Windows Server 2012
Необходимо открыть regedit для редактирования реестра, далее
редакторе реестра нужно отыскать раздел RDP-Tcp, сделать это можно, пройдя такой путь:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp:
В нем необходимо отыскать элемент PortNumber (как на картинке выше), и открыть этот параметр.
Далее следует переключиться в Десятичный (Decimal) формат ввода и задать новый порт для подключения по протоколу RDP:
При выборе нового порта для подключения необходимо помнить о том, что существует несколько категорий портов в разбивке по их номерам:
- Номера от 0 до 10213 — известные порты, которые назначаются и контролируются организацией IANA (Internet Assigned Numbers Authority).
Как правило, их используют различные системные приложения ОС. - Порты от 1024 до 49151 — зарегистрированные порты, назначаемые IANA. Их позволяется использовать для решения частных задач.
- Номера портов от 49152 до 65535 — динамические (приватные) порты, которые могут использоваться любыми приложениями или процессами для решения рабочих задач.
Правило для порта
После изменения порта для удаленного подключения, необходимо открыть его в настройках межсетевого экрана, иначе попытки внешнего соединения будут блокироваться.
Для этого, нужно воспользоваться оснасткой управления Брандмаэур Windows в режиме повышенной безопасности
Открыть ее можно, зайдя в меню: Диспетчер Серверов —> Средства.
В ней нужно выбрать пункт «Правила для входящих подключений», кликнуть по этому пункту правой кнопкой мыши и выбрать «Создать правило»:
Создадим правило для порта:
Нужно выбрать тип протокола (TCP или UDP) и указать порт, который мы задавали в ходе редактирования реестра
(в нашем примере — протокол TCP, номер порта 60000):
На следующем этапе нужно выбрать тип действия, которое описывает правило.
В нашем случае нужно разрешить подключение с использованием указанного порта.
На следующем шаге необходимо указать область действия правила — оно зависит от того, где работает сервер (в рабочей группе, домене, или частном доступе):
Затем нужно выбрать имя для правила (рекомендуется выбирать его таким образом, чтобы затем правило было легко узнать среди других):
После этого нужно перезагрузить сервер.
Теперь для подключения к нему по протоколу RDP нужно использовать новый порт.
Правило для порта
После изменения порта для удаленного подключения, необходимо открыть его в настройках межсетевого экрана, иначе попытки внешнего соединения будут блокироваться.
Для этого, нужно воспользоваться оснасткой управления Брандмаэур Windows в режиме повышенной безопасности
Открыть ее можно, зайдя в меню: Диспетчер Серверов —> Средства
Далее нужно выбрать пункт «Брандмаэур Windows в режиме повышенной безопасности»
В новом окне выбрать пункт «Правила для входящих подключений», кликнуть по этому пункту правой кнопкой мыши и выбрать «Создать правило»:
Мы будем создавать правило для порта:
Нужно выбрать тип протокола (TCP или UDP) и указать порт, который мы задавали в ходе редактирования реестра
(в нашем примере — протокол TCP, номер порта 60000):
На следующем этапе нужно выбрать тип действия, которое описывает правило.
В нашем случае нужно разрешить подключение.
На следующем шаге необходимо указать область действия правила — оно зависит от того, где работает сервер (в рабочей группе, домене, или частном доступе):
Затем нужно выбрать имя для правила
(рекомендуется выбирать его таким образом, чтобы затем правило было легко узнать среди других):
После этого нужно перезагрузить сервер.
Теперь для подключения к нему по протоколу RDP нужно использовать новый порт.
Двухфакторная аутентификация
Опытным системным администраторам и службам безопасности хорошо известно, что пользователи крайне не сознательны в вопросе соблюдения политик безопасности, они могут записать свои учетные данные на стикере и приклеить его рядом с компьютером, передать пароли своим коллегам и тому подобное. Особенно часто это происходит, когда пароль сложный (содержащий более 6 знаков и состоящий из букв разного регистра, цифр и специальных символов) и его трудно запомнить. А ведь такие политики администраторами задаются не просто так. Это необходимо для защиты учетной записи пользователя от простого перебора паролей по словарю. Также администраторы рекомендуют менять пароли хотя бы раз в 6 месяцев, просто из того соображения, что за это время теоретически можно отбрутфорсить даже сложный пароль.
Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя — это процесс подтверждения подлинности пользователя.
А двухфакторная аутентификация — это такая аутентификация, в которой необходимо использовать не менее двух различных способов для подтверждения своей личности.
Простейшим примером двухфакторной аутентификации в реальной жизни является сейф с замком и кодовой комбинацией. Чтобы открыть такой сейф необходимо знать код и владеть ключом.
Изменить срок действия кэшированного маркера TLS
Во время первоначальной проверки подлинности для EAP — TLS, PEAP — TLS и PEAP — MS — CHAP v2 сервер политики сети КЭШИРУЕТ часть свойств подключения TLS подключающегося клиента. Клиент также кэширует часть свойств подключения TLS NPS.
Каждая отдельная коллекция этих свойств подключения TLS называется маркером TLS.
Клиентские компьютеры могут кэшировать дескрипторы TLS для нескольких сторон проверки подлинности, в то время как НПСС может кэшировать дескрипторы TLS многих клиентских компьютеров.
Кэшированные обработчики TLS на клиенте и сервере позволяют более быстро выполнять процесс повторной проверки подлинности. Например, при повторной проверке подлинности беспроводного компьютера с NPS сервер политики сети может проверить обработчик TLS для беспроводного клиента и быстро определить, что клиентское подключение является переподключением. NPS разрешает подключение, не выполняя полную проверку подлинности.
Соответственно, клиент проверяет обработчик TLS для сервера политики сети, определяет, что он является повторно подключенным и не требует проверки подлинности сервера.
на компьютерах с Windows 10 и Windows Server 2016 срок действия маркера TLS по умолчанию составляет 10 часов.
В некоторых случаях может потребоваться увеличить или уменьшить время окончания срока действия маркера TLS.
Например, может потребоваться уменьшить срок действия маркера TLS в случаях, когда сертификат пользователя отзывается администратором, а срок действия сертификата истек. В этом случае пользователь по-прежнему может подключиться к сети, если NPS имеет кэшированный обработчик TLS, срок действия которого не истек. Уменьшение срока действия маркера TLS может помочь предотвратить повторное подключение таких пользователей с отозванными сертификатами.
Примечание
Лучшим решением для этого сценария является отключение учетной записи пользователя в Active Directory или удаление учетной записи пользователя из группы Active Directory, которой предоставлено разрешение на подключение к сети в политике сети. Однако распространение этих изменений на все контроллеры домена также может быть отложено из-за задержки репликации.
Дополнительные настройки удаленного рабочего стола.
меню «Пуск» — выполнить — gpedit.msc (редактор политик) — «конфигурация компьютера» — «конфигурация windows»- «локальные политики» — «параметры безопасности» — «ограничить использование пустых паролей…..» — «отключен»
Да, на младших версиях Windows, конечно, gpedit.msc не запускается (нет этой настройки)
Все бытовые версии Windows позволяют работать на ПК только одному пользователю — при входе нового пользователяWindows любезно предложит отключить другого пользователя
Это лицензионное ограничение для не серверных вариантов Windows — но выход есть. Немного шаманства — и все работает, смотреть здесь (открытие в новом окне)
Автоматический вход с сохраненным логином и паролем
Есть волшебная галочка «Разрешить мне сохранять учетные данные». Если запустить изменение еще раз — галочка сменится на «Всегда запрашивать учетные данные»
Получаем запрос на ввод данных, они сохраняются, вход на удаленную машину работает только по клику на ярлык.
А если учетные данные не сохраняются (в Windows 7 и старше)?
Или получаем предупреждение «Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»
Что делать?
Дело в том, что в последних версиях Windows пароль хранится не в rdp-файле, а в отдельном хранилище (Credential Manager — Диспетчер учетных данных). Как минимум — в групповых политиках должны быть отключены следующие параметры:
- Конфигурация пользователя — Административные шаблоны — Компоненты Windows — Службы удаленных рабочих столов — Клиент подключения к удаленному рабочему столу — Запретить сохранение паролей;
- Конфигурация компьютера — Административные шаблоны — Компоненты Windows — Службы удаленных рабочих столов — Клиент подключения к удаленному рабочему столу — Запретить сохранение паролей.
Вот можно почитать подробнее (откроется в новом окне)
Проверка подлинности была добавлена, начиная с Windows XP SP3. Но она там отключена по умолчанию (на Wibdows Vista уже включена).
Как включить проверку подлинности удаленного компьютера на Window XP SP3?
Идем в реестр regedit.exe (Выполнить)
Ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Открываем параметр Security Packages и ищем там слово tspkg. Если его нет, добавляем к уже существующим параметрам.
Ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
Открываем параметр SecurityProviders и добавляем к уже существующим провайдерам credssp.dll, если таковой отсутствует.
Закрываем редактор реестра. Перезагружаемся.
Если этого не сделать, то при попытке подключения компьютер запросит у нас имя пользователя и пароль, но вместо удаленного рабочего стола ответит следующее:
Подключение к удаленному рабочему столуОшибка при проверке подлинности(код 0×507)
При подключении появляется предупреждение системы безопасности Windows
«Не удается определить издателя этого удаленного подключения»
Это означает, что файл rdp не защищен подписанным сертификатом. Для локальной сети ничего страшного тут нет, можно поставить галочку «Больше не выводить запрос…»
Сама система безопасности работает следующим образом. Параметр политики позволяет указать, могут ли пользователи запускать на клиентском компьютере неподписанные файлы протокола удаленного рабочего стола (RDP) и RDP-файлы, полученные от неизвестных издателей.
Если этот параметр политики включен или не настроен, то пользователи могут запускать на клиентском компьютере неподписанные RDP-файлы и RDP-файлы, полученные от неизвестных издателей. Перед началом сеанса RDP пользователь получит предупреждение и запрос на подтверждение подключения.
Если этот параметр политики отключен, то пользователи не могут запускать на клиентском компьютере неподписанные RDP-файлы и RDP-файлы, полученные от неизвестных издателей. Если пользователь попытается начать сеанс RDP, то он получит сообщение о блокировке издателя.
Поддерживается: Не ниже Windows Vista с пакетом обновления 1 (SP1)
Registry Hive | HKEY_LOCAL_MACHINE |
Registry Path | SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services |
Value Name | AllowUnsignedFiles |
Value Type | REG_DWORD |
Enabled Value | 1 |
Disabled Value |
Читаем статью
Настройка Remoteapp через Gateway
Предположим, у нас есть опубликованное приложение Remoteapp и мы хотим подключаться к терминальному серверу через настроенный шлюз. Для этого открываем rdp-файл приложения на редактирование (например, блокнотом) и вносим в него изменения:
…
gatewayhostname:s:rdg.dmosk.local
gatewayusagemethod:i:1
…
* где:
- gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
- gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.
Пробуем подключиться.
предисловие
Автор ознакомился с большим количеством информации, прежде чем писать эту статью. Если есть ошибки, пожалуйста, попросите читателей представить их вовремя. Как правило, при использовании удаленного рабочего стола для подключения к Windows Server всегда появляется предупреждение, как показано на рисунке 1. Рисунок 1 Причина этого предупреждения заключается в том, что сертификат является самозаверяющим сертификатом сервера, и наш клиент не может его распознать, поэтому автор думает о том, как безопасно использовать удаленный рабочий стол (RDP) с использованием сертификата.
Решение:
- Используйте «Службу сертификации AD», поставляемую с WIndowsServer, для генерации всегоPKIТо есть, с полной системой сертификации, естественно, все соответствующие вопросы сертификации решены. Недостаток в том, что операция очень сложная, преимущество безопасное, коммерческого уровня!
- Использование OpenSSL для самостоятельного создания сертификата сэкономит много шагов по сравнению с первым методом. Он прост в использовании и подходит для разработки и тестирования. Недостатком является то, что уровень безопасности не может достигать высоты для коммерческого использования. сертификат)
О OpenCA:
OpenCA — проект с открытым исходным кодом для создания частногоPKI, Автор очень скудный и еще не изучал его. Я надеюсь, что читатели, которые более ясны в этом, расскажут мне, как применить его к аутентификации сервера удаленного рабочего стола. ^ — ^
Сложность:
- Клиент должен проверить статус отзыва сертификата при подключении к удаленному рабочему столу сервера. Есть два способа проверить статус отзыва сертификата:CRL и OSCP 1.1 OCSP По умолчанию параметр проверки пути сертификата использует OCSP, но поскольку мы являемся самозаверяющим сертификатом, Windows всегда будет запрашивать «Invalid Signer EKU» / «Invalid Signer EKU» при проверке, поэтому Мы не можем использовать этот метод для проверки статуса отзыва сертификата. 1.2 CRL Когда OCSP не может удовлетворить наши потребности, мы можем использовать только CRL для проверки статуса отзыва сертификата, поэтому нам также нужно использовать сайт для предоставления CRL
- Гибкое использование в OpenSSL, В настоящее время во многих статьях не говорится о том, как добавить в сертификат、Причиной получения информации о расширении является то, что применение расширения сертификата X509z не понято. Конечно, в нем упоминается много статей, но оно не указано четко, что может смутить читателей. x509v3_config — X509 V3 certificate extension configuration format
Binggui быстро, бой в реальном времени!
енаблеокспстаплингфорсни
ассоциация Online Certificate Status Protocol (OCSP) позволяет веб-серверу, например службы IIS (IIS), предоставлять текущее состояние отзыва сертификата сервера при отправке сертификата сервера клиенту во время подтверждения TLS.
Эта функция сокращает нагрузку на серверы OCSP, так как веб-сервер может кэшировать текущее состояние OCSP сертификата сервера и отправлять его нескольким веб-клиентам.
Без этой функции каждый веб-клиент попытается получить текущее состояние OCSP сертификата сервера с сервера OCSP.
При этом будет выдаваться высокая нагрузка на этот сервер OCSP.
Помимо служб IIS, веб-службы с http.sys могут также использовать преимущества этого параметра, в том числе службы федерации Active Directory (AD FS) (AD FS) и прокси-службу веб – приложения (WAP).
По умолчанию поддержка OCSP включена для веб-сайтов IIS, имеющих простую привязку SSL/TLS.
Однако эта поддержка не включена по умолчанию, если веб-сайт IIS использует один или оба следующих типа привязок SSL/TLS:
- Требовать указание имени сервера
- Использовать централизованное хранилище сертификатов
В этом случае ответ приветствия сервера во время подтверждения TLS не будет включать в себя состояние сшивания OCSP по умолчанию.
такое поведение повышает производительность. реализация сшивания Windows OCSP масштабируется до сотен сертификатов сервера.
Так как SNI и CCS позволяют IIS масштабироваться на тысячи веб-сайтов, которые могут иметь тысячи сертификатов сервера, установка этого поведения по умолчанию может привести к проблемам с производительностью.
применимые версии: все версии, начинающиеся с Windows Server 2012 и Windows 8.
Путь реестра:
Добавьте следующий ключ:
«Енаблеокспстаплингфорсни» = DWORD: 00000001
Чтобы отключить, присвойте параметру DWORD значение 0:
«Енаблеокспстаплингфорсни» = DWORD: 00000000
Примечание
Включение этого раздела реестра может повлиять на производительность.