RDP ошибка 0x80004005: подключение Windows 11 к Server 2019

Скорее всего причина — сбой TLS/SSL‑рукопожатия (RDPClient_SSL, TsSslStateHandshakeInProgress, код 0x80004005): на ПК2 не совпадают версии/наборы шифров или отсутствует доверие к сертификату сервера; также возможна несовместимость CredSSP/NLA, локальные политики (FIPS) или сохранённые неверные учётные данные. Быстрые исправления: сравнить настройки TLS/шифров и хранилища сертификатов между ПК1 и ПК2, обновить Windows и mstsc, временно отключить NLA для теста и при необходимости импортировать корневой сертификат сервера или выставить шифрование «Client Compatible».

Содержание

• Что означает ошибка и где «ломается» подключение
• Наиболее вероятные причины (кратко)
• Пошаговая диагностика — что проверить первым делом
• Конкретные исправления и команды
• Продвинутая проверка и сбор логов для анализа
• Быстрый чек‑лист действий для администратора
• Источники
• Заключение

Что означает RDP ошибка подключения 0x80004005 и TsSslStateHandshakeInProgress

Сообщение RDPClient_SSL с переходом из TsSslStateHandshakeInProgress в TsSslStateDisconnecting говорит о том, что TLS/SSL‑рукопожатие не завершилось корректно — клиент и сервер не смогли согласовать протокол/шифры или проверить сертификат, поэтому сессия обрывается (код 0x80004005 — «unspecified error» при рукопожатии). Это та же категория ошибок, о которых подробно пишут про SSL/TLS handshake и причины его срыва (несовпадение версий TLS, наборов шифров, неверное время, недоверенный сертификат) — см. обзор по SSL‑handshake для понимания механики работы протокола и типичных симптомов. https://kinsta.com/blog/ssl-handshake-failed/

На практике в RDP это часто даёт такие же симптомы: с одного компьютера (ПК1) подключение проходит, а с другого — нет. Почему? Потому что ПК1 и ПК2 могут иметь разную конфигурацию TLS/шифров, разные root‑сертификаты или разные патчи безопасности/политики — и один из участников отбрасывает соединение ещё на этапе рукопожатия. Подобные случаи описаны и в сообществах администраторов как частый источник ошибки 0x80004005 в RDP. https://techdirectarchive.com/2023/08/30/fix-remote-connection-issue-an-authentication-error-has-occurred-with-code-0x80004005/

Наиболее вероятные причины, почему ПК2 не подключается (RDP ошибка подключения)

Ниже — список причин с кратким объяснением, от самых частых к редким. Проверьте по порядку.

• Несовпадение версий TLS / отключён TLS 1.2 на клиенте. Сервер может требовать TLS 1.2+, а на ПК2 клиент либо не умеет его использовать, либо он отключён в реестре или политике.
• Недоверенный или просроченный сертификат сервера (цепочка не в Trusted Root). ПК1 может иметь корень сервера в хранилище, а ПК2 — нет. В логах это проявляется как обрыв на стадии проверки сертификата.
• Несовместимые наборы шифров (cipher suites) / включён режим FIPS на ПК2 или на сервере — тогда многие современные/старые шифры будут недоступны.
• Проблемы с CredSSP / Network Level Authentication (NLA). Обновления безопасности CredSSP или политика шифрования могут привести к тому, что клиент и сервер не договорятся об аутентификации.
• Неверный формат учётных данных (вы используете в ПК2 доменные учётные данные вместо локальных, или сохранённые в Credential Manager старые пароли). Сервер — в рабочей группе, поэтому важно явно указывать servername\user или .\user.
• Межсетевые ограничения / DPI / TLS‑инспекция (прокси/микрофайрвол/NGFW), которые подменяют сертификат и ломают TLS при проходе с ПК2 (часто корпоративные прокси ставят свой корень — на ПК1 он может быть добавлен, на ПК2 — нет).
• Отличия в версии mstsc или в настройках RDP ActiveX (если вы используете веб‑клиент). На ПК2 может быть более новая/бета версия или наоборот устаревшая.
• Блокировка порта 3389 на стороне клиента/межсетевого экрана (редко, т. к. лог показывает handshake, но стоит проверить).

Форумные обсуждения подтверждают, что именно TLS/сертификатные и CredSSP‑сценарии — самые обычные причины подобных RDPClient_SSL ошибок. https://sysadmins.online/threads/20134/

Пошаговая диагностика — что проверить в первую очередь (быстрый сценарий)

1. Сравните базовую связь.

• С ПК1 (работает) и с ПК2 запустите:
• PowerShell: Test-NetConnection -ComputerName <server> -Port 3389 — ожидаем tcpTestSucceeded : True.
• Простейшая проверка: ping <server> (если ICMP разрешён).
  Если на ПК2 tcpTestSucceeded = False — проблема с сетью/файрволом, а не с TLS.

2. Проверьте системное время и зону.

• TLS/сертификаты очень чувствительны к времени. Убедитесь, что время и дата на ПК2 синхронизированы.

3. Посмотрите логи на ПК2 (которые вы уже нашли) и в системном журнале Schannel.

• Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices‑RDPClient → Operational.
• System → проверьте сообщения Schannel (идентификаторы могут быть 36874, 36888 и т. п.) — они дают причину отказа TLS.

4. Проверьте доверие к сертификату RDP сервера.

• На ПК2 откройте mmc → Certificates (Computer account) → Trusted Root Certification Authorities и сравните с ПК1.
• На сервере экспортируйте сертификат (без приватного ключа) и попробуйте импортировать его в Trusted Root на ПК2 (временный тест).

5. Сравните настройки TLS/шифров на ПК1 и ПК2.

• Запустите PowerShell (Admin): Get-TlsCipherSuite — сравните списки.
• Посмотрите реестр: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ — есть ли отключенные протоколы (TLS 1.0/1.1/1.2)?

6. Проверьте политики и обновления.

• На ПК2 выполните gpresult /h C:\gp_pc2.html и сравните ключевые политики безопасности с ПК1.
• Убедитесь, что на ПК2 установлены последние обновления безопасности (патчи CredSSP/NLA). Иногда несинхронизированные патчи ломают аутентификацию.

7. Быстрый функциональный тест: отключите NLA на сервере (временно) и попробуйте подключиться с ПК2.

• Если после отключения NLA подключение проходит — проблема в CredSSP/NLA и связана с аутентификацией (обновления/политики). Не оставляйте NLA отключённым надолго — это понижает безопасность.

8. Попробуйте альтернативный клиент.

• Установите Microsoft Remote Desktop из Microsoft Store или используйте другую версию mstsc на ПК2 — это поможет исключить баг клиента.

Конкретные исправления и команды (регистрация, GPO и быстрые правки)

Ниже — проверенные шаги с командами/шагами. Делайте backup реестра и снимки конфигурации перед изменениями.

1. Включить TLS 1.2 на клиенте и сервере (если отключён). В PowerShell/командной строке админа можно выполнить:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f

Перезагрузка требуется для применения.

2. Установите на сервер шифрование совместимое с клиентом. В Group Policy (или локально gpedit.msc):

• Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
• «Require use of specific security layer for remote (RDP) connections» — установить в «Not configured» или выбрать «RDP»/«Negotiate» для теста.
• «Set client connection encryption level» — поставить «Client Compatible».
  Эти настройки уменьшат жёсткость требований к шифрованию и помогут понять, в TLS ли проблема.

3. Экспорт/импорт сертификата RDP сервера (для теста доверия).

• На сервере: mmc → Certificates (Computer account) → Personal (или Remote Desktop) → найдите сертификат с именем сервера → All Tasks → Export → выберите экспорт без приватного ключа (.CER).
• На ПК2: открыть .CER → Install Certificate → Local Machine → Trusted Root Certification Authorities. После этого попробуйте снова подключиться.

4. Очистите сохранённые креды и явно укажите имя учётной записи.

• Credential Manager → Windows Credentials → удалить связанные записи для сервера.
• В MSTSC используйте формат логина SERVERNAME\username или . \username (точка + слэш) для локальной учётной записи.

5. Обновления и исправления для CredSSP/NLA.

• На обеих машинах (ПК2 и сервер) установить последние обновления Windows. При подозрении на несовместимость CredSSP лучше обновить, чем применять временные реестровые «обходы». Подлинное решение — синхронные обновления.

6. Проверка DPI / TLS‑инспекции.

• Если трафик идёт через корпоративный прокси/NGFW с TLS‑инспекцией, убедитесь, что сертификат инспектора доверен на ПК2 или исключите порт 3389 из инспекции.

7. Тесты с переключением транспорта.

• RDP поддерживает мультитранспорт (UDP). Если логи показывают «Мультитранспортное подключение разорвано», временно отключите UDP (в реестре клиента) или принудите mstsc использовать только TCP для теста. (Это диагностический шаг; изменений в сервере обычно не требуется.)

Продвинутая проверка и сбор логов для аналитики (Wireshark, Schannel)

• Запись трафика: сделайте захват на ПК2 при попытке подключения, фильтр: tcp.port==3389. В Wireshark ищите TLS ClientHello и серверный TLS Alert (handshake_failure или bad_certificate). Это покажет, какой шаг рукопожатия упал.
• Schannel: в System log ищите события Schannel — они дают текстовую причину (например, unsupported_protocol, bad_certificate).
• Экспорт логов RDP клиента:
• wevtutil epl "Microsoft-Windows-TerminalServices-RDPClient/Operational" C:\temp\RDPClient.evtx
• wevtutil epl System C:\temp\System.evtx
  Эти файлы можно переслать в службу поддержки.
• Сравните Get-TlsCipherSuite и Get-ComputerInfo на ПК1 и ПК2 — заметите отличия в порядке/наличии шифров.
• Для оценки набора шифров на сервере можно использовать nmap с скриптом ssl-enum-ciphers (если доступно) или сторонние утилиты типа IISCrypto для наглядной настройки.

Быстрый чек‑лист действий (для занятых администраторов)

1. Test‑NetConnection -Port 3389 — убедиться, что порт доступен.
2. Синхронизировать время на ПК2.
3. Убедиться, что ПК2 имеет те же корневые сертификаты, что и ПК1 (импорт cert сервера в Trusted Root для теста).
4. Обновить Windows и mstsc на ПК2 (и на сервере).
5. Временно отключить NLA на сервере — проверить, подключается ли ПК2.
6. Включить TLS 1.2 (реестр) на клиенте/сервере и перезагрузить.
7. Сравнить групповые политики/политику FIPS между ПК1 и ПК2.
8. Если корпоративный прокси/NGFW — проверить TLS‑инспекцию и доверие CA.
9. Собрать логи (RDPClient.evtx, System/Schannel) и, при необходимости, сделать Wireshark‑трейс.

Источники

• Fix Remote Connection Issue: An Authentication Error Has Occurred with Code 0x80004005
• How to Fix “SSL Handshake Failed” & “Cloudflare 525” Error (Kinsta)
• Форум: ошибка RDPClient_SSL — sysadmins.online
• 0x80004005 — варианты решения (Remontka.pro)
• Ошибки RDP: обзор (mclouds.ru)

Заключение

RDP ошибка подключения с 0x80004005 и сообщением о TsSslStateHandshakeInProgress почти всегда указывает на проблему TLS/SSL‑рукопожатия (сертификаты, версии TLS, наборы шифров или CredSSP/NLA). Сравните конфигурации ПК1 и ПК2 (сертификаты, TLS, политики), обновите системы, временно выключите NLA для теста и импортируйте корневой сертификат сервера на ПК2 — эти шаги решают большинство таких случаев. Если после выполнения всех проверок проблема остаётся, соберите логи Schannel и RDPClient и отправьте их для глубокого анализа (Wireshark/evtx).