RDP с Windows 11 на Windows 10: ошибка 0x904, расширенный код 0x7

Симптомы: порт открыт, а сеанса нет

• Клиент Windows 11 сообщает код 0x904, расширенный код 0x7.
• Windows 10 принимает TCP-соединение на порт 3389.
• Запуск mstsc /admin и отключение UDP на клиенте не решают проблему.
• В системном журнале принимающего компьютера появляется Schannel 36870, код 0x8009030D, внутреннее состояние 10001.

Сами коды 0x904 и 0x7 не доказывают проблему сертификата. Вывод в этом случае основан на сочетании доступного порта, принятого соединения и ошибки Schannel.

1. Отделяем сетевую проблему от TLS

На Windows 11 проверьте порт. Замените PC-WIN10 на имя или IP принимающего компьютера:

Test-NetConnection -ComputerName "PC-WIN10" -Port 3389

Значение TcpTestSucceeded : True подтверждает установление TCP-соединения в момент проверки, но не успешное согласование TLS или вход пользователя. Если порт недоступен, начните с проверки слушателя RDP и порта 3389.

2. Проверяем Schannel на Windows 10

Сразу после неудачной попытки подключения прочитайте последние события:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    StartTime = (Get-Date).AddMinutes(-10)
} | Where-Object ProviderName -eq 'Schannel' |
    Select-Object TimeCreated, Id, Message | Format-List

В нашем случае сообщение 36870 указывало на невозможность обращения к закрытому ключу учётных данных TLS server. Одновременно журнал TerminalServices-RemoteConnectionManager фиксировал полученное слушателем соединение. Это направило проверку к сертификату и его ключу на Windows 10.

3. Проверяем сертификат, привязку и права

Узнайте, какой сертификат назначен слушателю, и сохраните исходный отпечаток для возможного возврата:

$rdp = Get-WmiObject -Namespace 'root\cimv2\TerminalServices' `
    -Class Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'"
$oldThumbprint = $rdp.SSLCertificateSHA1Hash
$rdp | Select-Object TerminalName, SSLCertificateSHA1Hash, SSLCertificateSHA1HashType

Откройте certlm.msc — сертификаты локального компьютера. Проверьте хранилища «Личное» и «Удалённый рабочий стол», срок действия, назначение «Проверка подлинности сервера» и наличие закрытого ключа. Признак HasPrivateKey=True не гарантирует, что службе разрешено читать ключ.

Для назначенного сертификата в хранилище «Личное» откройте «Все задачи → Управление закрытыми ключами» и проверьте право чтения для NETWORK SERVICE. Не выдавайте права всем пользователям и не изменяйте разрешения всего каталога MachineKeys.

Почему возник запрос PIN криптопровайдера

На компьютере были сторонние криптопровайдеры. При попытке создать сертификат возникал запрос PIN аппаратного ключа. Это отдельный диагностический признак: служебный ключ RDP должен быть доступен службе без интерактивного ввода PIN. Для программного ключа нужно явно выбирать подходящий программный провайдер.

4. Пример восстановления сертификата

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

Для диагностического самоподписанного сертификата можно явно задать программный RSA-провайдер:

$params = @{
    DnsName = $env:COMPUTERNAME
    CertStoreLocation = 'Cert:\LocalMachine\My'
    Provider = 'Microsoft Enhanced RSA and AES Cryptographic Provider'
    KeyAlgorithm = 'RSA'
    KeyLength = 2048
    HashAlgorithm = 'SHA256'
    KeySpec = 'KeyExchange'
    KeyExportPolicy = 'NonExportable'
    NotAfter = (Get-Date).AddYears(1)
    Type = 'SSLServerAuthentication'
}
$cert = New-SelfSignedCertificate @params
$cert | Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Продолжайте только если сертификат создан без ошибок и содержит закрытый ключ. Самоподписанный сертификат не становится автоматически доверенным на клиенте; имя и цепочку доверия проверяют отдельно. Не отключайте проверку сертификатов для обхода предупреждения.

Через certlm.msc назначьте NETWORK SERVICE право чтения закрытого ключа нового сертификата. Затем привяжите его к слушателю:

$rdp.SSLCertificateSHA1Hash = $cert.Thumbprint
$null = $rdp.Put()

Get-WmiObject -Namespace 'root\cimv2\TerminalServices' `
    -Class Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'" |
    Select-Object TerminalName, SSLCertificateSHA1Hash

Убедитесь, что отпечаток совпадает с новым сертификатом. При наличии резервного доступа перезапустите службу:

Restart-Service TermService -Force

5. Проверяем результат

Повторно подключитесь с Windows 11, проверьте вход и работу сеанса. Затем убедитесь, что для новой попытки не появляются свежие ошибки Schannel 36870. Одного открытого порта для проверки результата недостаточно.

Что не решило проблему

• Подключение через mstsc /admin.
• Отключение UDP на клиенте.
• Удаление старого сертификата в расчёте на автоматический перевыпуск: после перезапуска службы и перезагрузки новый сертификат не появился.

При похожих симптомах проверяйте журналы и фактическую привязку сертификата. Не удаляйте сертификаты и ключи «на всякий случай».

Документация

• Microsoft: сертификат слушателя RDP, привязка и права на закрытый ключ — документация для Windows Server; применимость проверяйте на своей системе.
• Microsoft: New-SelfSignedCertificate.

Материал основан на решённом практическом случае. Данные клиента обезличены. Обновлено 6 октября 2026 года.