Сертификат RDP-сервера: как посмотреть, заменить самоподписанный и убрать предупреждение

Сертификат RDP-сервера по умолчанию самоподписанный: он живёт около шести месяцев, пересоздаётся сам, и клиент каждый раз ругается на недоверенного издателя. Лечится сертификатом от внутреннего центра сертификации, привязанным к слушателю RDP-Tcp. Ниже: как посмотреть текущий сертификат, заменить его и раздать доверие через GPO.

Откуда берётся предупреждение о сертификате при подключении по RDP

Я давно ставлю и сопровождаю удалённый доступ к серверам в небольших компаниях, и вопрос про сертификат RDP-сервера звучит почти в каждом проекте. Сотрудник открывает mstsc, вводит имя сервера и видит окно: «Не удалось проверить подлинность удалённого компьютера. Продолжить подключение?». Он нажимает «Да», потому что так нажимали все до него. Проблема не в окне, а в привычке. Человек, который ежедневно подтверждает сомнительный сертификат, однажды так же подтвердит и подменённый.

Причина простая. Если вы ничего не настраивали, сервер сам создаёт самоподписанный сертификат и использует его для проверки подлинности. Клиент не находит издателя этого сертификата в доверенных корневых центрах и честно предупреждает. По документации Microsoft, самоподписанный сертификат RDP по умолчанию действует шесть месяцев, а когда срок истекает, сервер создаёт новый. Поэтому даже если один раз добавить сертификат в доверенные на рабочем месте, примерно через полгода предупреждение вернётся, и в поддержку снова пойдут заявки.

Есть и второй симптом, о котором мало кто думает. У клиентов с самоподписанным сертификатом экран «Securing remote connection» (защита удалённого подключения) может висеть заметное время: система пытается получить из интернета список доверенных центров сертификации, чтобы проверить издателя и статус отзыва. Microsoft описывает это в статье про зависание подключения. Так что правильный сертификат даёт не только спокойствие по безопасности, но и более быстрое подключение.

Эта статья про сертификат на самом RDP-сервере: где он лежит, как его увидеть, чем заменить и как сделать так, чтобы предупреждение исчезло у всех 40 с лишним пользователей разом. Про ситуацию, когда сертификат повреждён и вход заканчивается внутренней ошибкой, я уже писал отдельно: внутренняя ошибка RDP разбирается там, здесь мы говорим о штатной настройке.

Как посмотреть, какой сертификат использует RDP-сервер

Сначала нужно понять, что сейчас вообще используется. Самоподписанный сертификат лежит не в привычном хранилище «Личное», а в отдельном хранилище «Удалённый рабочий стол» (Remote Desktop) учётной записи компьютера. Откройте certlm.msc и разверните «Удалённый рабочий стол» > «Сертификаты». Именно по этому пути Microsoft предлагает экспортировать сертификат, если его нужно вручную добавить в доверенные на клиенте. Сертификаты, выпущенные вашим центром сертификации, обычно лежат в хранилище «Личное» компьютера.

Важно другое: хранилище само по себе не говорит, какой сертификат реально привязан к слушателю. Привязка хранится в свойстве SSLCertificateSHA1Hash класса Win32_TSGeneralSetting в пространстве имён root\cimv2\TerminalServices. Рядом есть свойство SSLCertificateSHA1HashType, оно показывает состояние: по документации Microsoft 1 означает самоподписанный сертификат по умолчанию, 2 означает сертификат, назначенный групповой политикой, 3 означает собственный (Custom), 0 означает недействительное значение. Эти два свойства и нужно смотреть. Запускайте PowerShell от администратора на самом сервере.

Get-CimInstance -Namespace root\cimv2\TerminalServices -ClassName Win32_TSGeneralSetting |
  Where-Object TerminalName -eq 'RDP-Tcp' |
  Select-Object TerminalName, SSLCertificateSHA1Hash, SSLCertificateSHA1HashType, SecurityLayer, UserAuthenticationRequired

Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' | Format-List Subject, Thumbprint, NotAfter
Get-ChildItem 'Cert:\LocalMachine\My' | Format-List Subject, Thumbprint, NotAfter

Дальше сравниваем отпечаток из первой команды с отпечатками в двух хранилищах. Совпал с «Удалённым рабочим столом» и тип равен 1 — используется самоподписанный сертификат, и надо его менять. Совпал с сертификатом в «Личном» — привязка уже ручная или по политике. Я всегда смотрю и NotAfter: просроченный сертификат в «Личном» способен тихо вернуть вас к предупреждению. Команды, особенно через Get-CimInstance, проверьте на своей версии Windows Server: в документации по классу сам доступ к пространству имён описан через WMI, а часть примеров Microsoft написана через Get-WmiObject. Если опрашиваете сервер удалённо, учтите требование из той же документации: подключение к root\cimv2\TerminalServices должно идти с уровнем аутентификации Packet Privacy, для Get-WmiObject это ключ -Authentication PacketPrivacy.

Чем заменить самоподписанный сертификат: требования и варианты

Вариантов три, и выбор зависит от размера вашей инфраструктуры. Первый — сертификат от внутреннего центра сертификации домена (AD CS). Для компании на 40–50 мест с доменом это мой основной выбор: бесплатно, срок и шаблон под вашим контролем, а доверие на клиентах раздаётся групповой политикой. Второй — сертификат публичного центра сертификации для имени, которое реально резолвится в интернете. Он нужен, если подключаются с неуправляемых компьютеров, на которые корневой сертификат компании не поставить. Третий — тот же самоподписанный сертификат, но выпущенный вами на нужный срок и вручную распространённый по клиентам. Это допустимо для одного-двух серверов, но плохо масштабируется.

Требования к сертификату такие. Он должен быть установлен в хранилище «Личное» учётной записи компьютера (через certlm.msc), иначе при попытке привязки получите ошибку Invalid Parameter, на это прямо указывает Microsoft. Он должен быть пригоден для проверки подлинности сервера, а имя в нём должно совпадать с тем, по которому подключаются клиенты. Если пользователи набирают srv-rdp01.club.example.com, имя в сертификате должно быть именно таким (в Subject или в альтернативных именах). Подключение по IP-адресу почти наверняка вызовет предупреждение даже с идеальным сертификатом, поэтому я приучаю людей к имени.

И ещё одно условие, о котором забывают: у службы удалённых рабочих столов должен быть доступ к закрытому ключу. Microsoft пишет, что служба работает под учётной записью NETWORK SERVICE, и для файла ключа нужно выдать ей право на чтение. Делается это в консоли сертификатов: правый клик на сертификате, «Все задачи», «Управление закрытыми ключами», добавить NETWORK SERVICE и поставить «Чтение». Если права не выданы, привязка пройдёт, а подключение не заработает, и вы получите ровно ту ситуацию, которую я разбирал в статье про внутреннюю ошибку RDP.

Если у вас пока нет центра сертификации и нужно срочно, можно выпустить самоподписанный сертификат вручную. Командлет New-SelfSignedCertificate по документации Microsoft предназначен для тестовых целей, по умолчанию создаёт сертификат SSL-сервера и действует один год, если не указать NotAfter. Для боевого сервера это временная мера, но она лучше случайного сертификата, который пересоздаётся каждые полгода.

New-SelfSignedCertificate -DnsName 'srv-rdp01.club.example.com' -CertStoreLocation 'Cert:\LocalMachine\My' -NotAfter (Get-Date).AddYears(2)

Как привязать новый сертификат к слушателю RDP-Tcp

Просто положить сертификат в хранилище мало. Он должен быть назначен слушателю RDP. По моему опыту, подмена сертификата в хранилище «Удалённый рабочий стол» ничего не меняет в том, какой сертификат использует RDP при согласовании TLS: нужно переписать привязку. Microsoft в статье про конфигурации сертификата слушателя (бывшая KB3042780) описывает два способа: WMI и реестр. Для Windows Server 2025 и Windows 11 приводится PowerShell-команда с Set-WmiInstance, для Windows Server 2012 и более старых версий — wmic. Важная оговорка: эта статья про серверы, которые не входят в развёртывание RDS с брокером подключений. Если у вас полноценное развёртывание, сертификаты ролей назначаются в диспетчере серверов: Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > Certificates, и ручная привязка через WMI там не нужна.

Сначала получаем отпечаток. Копировать его из окна свойств сертификата рискованно: Microsoft предупреждает, что вместе со строкой может скопироваться невидимый символ ASCII, из-за которого команда не сработает. Я беру отпечаток прямо из PowerShell, это снимает проблему. Затем записываем его в свойство SSLCertificateSHA1Hash.

$thumb = (Get-ChildItem 'Cert:\LocalMachine\My' |
  Where-Object { $_.Subject -like 'CN=srv-rdp01*' } |
  Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint

Get-CimInstance -Namespace root\cimv2\TerminalServices -ClassName Win32_TSGeneralSetting |
  Where-Object TerminalName -eq 'RDP-Tcp' |
  Set-CimInstance -Property @{ SSLCertificateSHA1Hash = $thumb }

Вариант из документации Microsoft для Windows Server 2025 и Windows 11 выглядит так: Get-WmiObject -class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices | Set-WmiInstance -Arguments @{SSLCertificateSHA1Hash="THUMBPRINT«}. Для Windows Server 2012 и более старых версий в той же статье приведена команда wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=»THUMBPRINT". Утилита wmic в новых системах считается устаревшей, поэтому опирайтесь на PowerShell и проверяйте результат на тестовой машине.

Есть и реестровый способ: значение SSLCertificateSHA1Hash типа REG_BINARY в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, где отпечаток записан байтами через запятую без пробелов. Я им пользуюсь редко: руками ошибиться проще. После привязки повторите команду просмотра из прошлого раздела. Тип должен смениться на 3 (собственный сертификат), а отпечаток совпасть с вашим. Подключитесь с другой машины и убедитесь, что в свойствах сертификата в окне подключения именно он. Новые сеансы получают новый сертификат, а вот нужна ли перезагрузка службы TermService для уже работающих сеансов, зависит от версии, поэтому не перезапускайте её в рабочее время, пока не проверите на тестовой.

Как автоматически выдавать сертификаты RDP через GPO и шаблон AD CS

Когда серверов больше одного, привязывать вручную надоедает, а главное — через полгода-год всё равно придётся повторять. Здесь выручает групповая политика «Server authentication certificate template» (шаблон сертификата проверки подлинности сервера). Путь по документации Microsoft: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security. Сервер ищет сертификат, созданный по указанному шаблону, и автоматически выбирает его для проверки подлинности.

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

Теоретически схема такая. В центре сертификации вы создаёте шаблон для RDP-серверов (дублируете подходящий шаблон проверки подлинности сервера), на вкладке «Безопасность» даёте группе серверов права Read и Enroll (без Enroll сервер не сможет сам отправить запрос, о котором говорит политика), при желании ещё Autoenroll, и публикуете шаблон на центре сертификации. Затем в групповой политике на подразделение с RDP-серверами указываете имя шаблона; автоматическую регистрацию сертификатов для компьютеров я включаю там же, чтобы продление шло штатным механизмом. Укажите именно имя шаблона, а не отображаемое имя: на этом спотыкаются часто, и в своей среде это стоит проверить. Подробно про инфраструктуру открытых ключей в домене я писал в материале центр сертификации Active Directory, там же разобрано, как не наступить на типовые грабли с CA.

Саму политику удобно привязывать к отдельному подразделению, а не ко всему домену, и тестировать на одном сервере. Общие принципы организации политик, порядок применения и откат я собрал в статье про рекомендации по групповым политикам. После применения политики выполните gpupdate /force на сервере, посмотрите, что в хранилище «Личное» появился сертификат по шаблону, и снова проверьте SSLCertificateSHA1HashType: по документации значение 2 означает сертификат, назначенный групповой политикой.

Как убрать предупреждение на клиентах и каких ошибок избегать

Серверная часть решает половину задачи. Предупреждение уйдёт, только если клиент доверяет издателю сертификата и подключается по тому имени, которое в сертификате. С сертификатом внутреннего центра сертификации на компьютерах домена доверие обычно уже есть: корневой сертификат корпоративного CA попадает в доверенные автоматически через Active Directory. Это ещё один довод за домен и AD CS. Для компьютеров вне домена корневой сертификат нужно поставить в «Доверенные корневые центры сертификации» вручную или другим средством распространения.

Если вы остаётесь на самоподписанном сертификате, Microsoft описывает ручной путь. На сервере экспортируйте сертификат из хранилища «Удалённый рабочий стол» через вкладку «Состав» и «Копировать в файл», а на клиенте импортируйте его в «Доверенные корневые центры сертификации» компьютера. Там же сказано, что после пересоздания сертификата (а это раз в шесть месяцев) операцию придётся повторить. Вот почему я не люблю этот путь для чего-либо, кроме одного тестового сервера.

Отдельно про зависание на «Securing remote connection». Microsoft предлагает два обходных пути: добавить самоподписанный сертификат в доверенные на клиенте или выключить автоматическое обновление корневых сертификатов групповой политикой (Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings > Turn off Automatic Root Certificates Update). Второй способ я не использую: Microsoft сама предупреждает, что тогда придётся обновлять корневые сертификаты на всех машинах вручную. Правильный сертификат закрывает вопрос без таких жертв.

Что я проверяю после всего: подключение по полному имени (FQDN), отсутствие окна предупреждения, срок действия NotAfter с запасом, а также что включена проверка подлинности на уровне сети (NLA). Поле UserAuthenticationRequired в Win32_TSGeneralSetting у Microsoft описано как требование проверки подлинности пользователя при подключении. Про безопасную публикацию RDP наружу, когда прямое открытие порта 3389 в интернет нежелательно, я рассказывал в статье про шлюз удалённых рабочих столов: там сертификат нужен уже на самом шлюзе, и это отдельная история.

Теперь о типичных ошибках при замене сертификата RDP. Самая частая — сертификат есть, привязка не сделана. Вторая — закрытый ключ недоступен службе: нет права чтения у NETWORK SERVICE. Третья — в сертификате имя не совпадает с тем, по которому подключаются. Четвёртая — сертификат лежит не в том хранилище: привязка к сертификату, которого нет в «Личном» компьютера, заканчивается ошибкой Invalid Parameter. Пятая — ручная привязка конфликтует с политикой, и сервер упорно остаётся на старом сертификате.

Отдельно напомню про безопасность. Не отключайте проверку подлинности на уровне сети ради того, чтобы «заработало со старым клиентом». В описании свойства UserAuthenticationRequired Microsoft прямо пишет, что NLA повышает защиту сервера от сетевых атак, а подключаться при нём могут только клиенты RDP 6.0 и новее, то есть любой современный mstsc. Также не пытайтесь заблокировать создание самоподписанного сертификата правами на разделы реестра: официально такой способ нигде не описан, а на практике он приводит к ошибкам в журнале и иногда ломает подключение.

Мой порядок действий короткий. Первое: посмотреть текущую привязку и срок действия. Второе: выпустить сертификат нужного имени и проверить права на ключ. Третье: привязать его к RDP-Tcp или настроить политику с шаблоном. Четвёртое: проверить подключение по FQDN с обычного рабочего места. Пятое: поставить напоминание за 30 дней до окончания срока, если автоматическое продление не настроено. Если у вас нет времени заниматься этим самостоятельно, мы в АйТи-Фреш делаем такую настройку за один выезд или удалённо.

Разбор из практики: спортивный клуб «Клуб Победа», 44 рабочих места

Клиент у нас условный, но ситуация знакомая. Спортивный клуб, 44 рабочих места, домен на двух контроллерах, два отдельных сервера терминального доступа без брокера подключений (Windows Server 2022), где сотрудники ресепшена и бухгалтерии работают с учётной программой. К нам обратились с жалобой: «каждый день вылезает красное окно про сертификат, мы уже все нажимаем “Да”». Выяснилось, что на обоих серверах использовался самоподписанный сертификат по умолчанию, а имена в окнах подключения у сотрудников были смешанные: у кого-то IP, у кого-то короткое имя.

Домен у клиента уже имел внутренний центр сертификации, но использовался он только для других задач. План занял один рабочий день на двух людей. Утром я создал шаблон для RDP-серверов на базе стандартного шаблона проверки подлинности сервера, выдал группе терминальных серверов права Read, Enroll и Autoenroll и опубликовал его, срок действия выставил два года. Днём создал групповую политику «Server authentication certificate template» на подразделение с терминальными серверами и сначала проверил её на втором сервере. Сертификат по шаблону появился в хранилище «Личное», а SSLCertificateSHA1HashType стал равен 2, как и описано в документации.

Первый сервер перевели вечером, после закрытия клуба. На нём когда-то давно сертификат привязывали вручную, поэтому политика не сработала, пока мы не вернули привязку по умолчанию, ровно по правилу из документации о приоритете ручного выбора. Затем мы разослали сотрудникам ярлыки подключения с полными именами серверов и попросили больше не использовать IP-адреса. Итог: окно с предупреждением исчезло у всех 44 человек, заявки по этой теме прекратились, а сертификат продлевается автоматически, поэтому полугодовой «сюрприз» с пересозданным самоподписанным сертификатом больше не повторяется.

Частые вопросы