// DevOps

Windows Server 2019: RDP dejó de conectarse, aunque el puerto 3389 está abierto. Diagnóstico y solución del error ID de evento 1057

Publicado el 08.07.2026

Introducción

Uno de los escenarios desagradables en Windows Server es cuando Remote Desktop deja de funcionar de repente, aunque desde fuera todo parezca “casi normal”:

el puerto 3389 está abierto;
el servicio Remote Desktop Services está iniciado;
el firewall no bloquea la conexión;
qwinsta muestra que rdp-tcp escucha;
pero no se puede conectar ni siquiera como administrador;
RemoteApp tampoco funciona, porque el RDP básico no levanta la sesión.

En mi caso el problema se manifestó en Windows Server 2019 con RDS/RemoteApp. Al principio parecía que se había roto RemoteApp, pero el diagnóstico rápidamente mostró: el problema está más abajo, a nivel de RDP TLS / certificado / SChannel.

Síntoma clave en el Visor de eventos:

Event ID: 1057
Provider: Microsoft-Windows-TerminalServices-RemoteConnectionManager

Al servidor del host de sesiones de Escritorio remoto no se le pudo crear
un nuevo certificado autofirmado para usar al autenticar el servidor del host
de sesiones de Escritorio remoto en las conexiones SSL.

Código de estado: Se especificó un algoritmo incorrecto.

En este artículo veremos:

cómo diagnosticar correctamente esta falla;
cómo entender que el puerto está abierto pero RDP aún no funciona;
por qué deshabilitar TLS devuelve el acceso temporalmente;
cómo restaurar el funcionamiento normal de RDP mediante un certificado correcto;
por qué no se debe dejar SecurityLayer = 0;
qué comprobar después de la reparación;
cómo recuperar RemoteApp/RDWeb tras arreglar el RDP básico.

1. Síntomas

Inicialmente el problema se veía así:

los usuarios no pueden iniciar RemoteApp;
una conexión RDP normal tampoco funciona;
ni siquiera entra el administrador;
el puerto 3389 está abierto;
los servicios RDP están iniciados.

Qué ve el usuario en el cliente

Desde el lado del cliente mstsc esta falla aparece de distintas formas dependiendo de la versión del cliente y de las opciones de conexión. Normalmente es uno de dos mensajes.

Primera variante — concisa:

Se produjo un error interno.

En la versión en inglés del cliente:

An internal error has occurred.

Segunda variante — con códigos:

No se pudo conectar a la sesión remota porque se agotó el tiempo
destinado para establecer la conexión o se produjo un error.

Código de error: 0x904
Código de error ampliado: 0x7

Ambos mensajes son el mismo problema, visto desde distintos lados. El cliente establece la conexión TCP al 3389, inicia el handshake TLS — y el servidor corta la conexión, porque no puede presentar un certificado. El cliente no sabe por qué el servidor cortó la sesión, por eso muestra la genérica “Se produjo un error interno” o el código 0x904 con código ampliado 0x7.

Conclusión importante para el diagnóstico: si el cliente muestra “Se produjo un error interno” o 0x904 / 0x7, no hace falta intentar descifrar más los códigos en el cliente. La causa real está en el servidor, y hay que buscarla en el registro de eventos del servidor, no en el cliente.

Estado de los servicios en el servidor

En el servidor los servicios se veían así:

powershell
Get-Service TermService,SessionEnv,UmRdpService,W3SVC -ErrorAction SilentlyContinue |
Select-Object Name,DisplayName,Status,StartType

Ejemplo de salida:

Name         DisplayName                                                                     Status   StartType
----         -----------                                                                     ------   ---------
SessionEnv   Configuración del servidor de Escritorio remoto                                  Running  Manual
TermService  Servicios de Escritorio remoto                                                  Running  Manual
UmRdpService Redireccionador de puertos en modo de usuario para los servicios de Escritorio remoto Running  Manual
W3SVC        Servicio de publicación web                                                     Stopped  Disabled

En esta fase es importante no sacar conclusiones erróneas.

W3SVC es necesario para IIS y RD Web Access. Si está detenido, el portal web de RemoteApp puede no estar disponible. Pero W3SVC por sí solo no debería romper el mstsc normal en el puerto 3389.

Si ni siquiera funciona el RDP directo, hay que arreglar primero el RDP básico y después volver a RemoteApp/RDWeb.

2. División importante: puerto abierto ≠ RDP funcional

Una trampa muy común: el administrador comprueba el puerto 3389, ve que está abierto, y piensa que RDP debería funcionar.

Por ejemplo:

powershell
Test-NetConnection server.example.com -Port 3389

O desde Linux/macOS:

bash

nc -vz server.example.com 3389

Si el puerto TCP está abierto, eso demuestra sólo una cosa: se puede establecer una conexión TCP al 3389 del servidor.

Eso no demuestra que funcionen correctamente después:

el listener de RDP;
la WinStation RDP-Tcp;
el handshake TLS;
NLA;
CredSSP;
certificado RDP;
derechos de inicio interactivo;
licenciamiento RDS;
la colección RemoteApp.

En mi caso el puerto estaba abierto, pero la parte TLS de RDP no funcionaba.

3. Primer nivel de diagnóstico: ¿escucha el listener RDP?

En el servidor hay que comprobar el estado de las sesiones RDP:

cmd

qwinsta

cmd

query session

En mi caso la salida fue así:

SESION            USUARIO                  ID  ESTADO  TIPO        DISPOSITIVO
services                                   0  Desconectado
>console           Administrador             1  Activo
rdp-tcp                                65536  Escucha

La línea:

rdp-tcp  65536  Escucha

significa que el listener RDP existe y está en estado de aceptar conexiones.

También hay que comprobar si los inicios de sesión están habilitados:

cmd

change logon /query

Salida normal:

Iniciar sesión desde sesiones ahora está ACTIVADO

Si los inicios están deshabilitados, los activamos:

cmd

change logon /enable

4. Comprobamos si RDP está deshabilitado en el registro

La configuración básica de RDP se guarda aquí:

powershell
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' |
Select-Object fDenyTSConnections

Valor normal:

fDenyTSConnections : 0

Si está 1, RDP está prohibido:

powershell
Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name fDenyTSConnections `
  -Value 0

5. Comprobamos parámetros de RDP-Tcp

A continuación miramos la configuración del propio listener RDP:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object `
  PortNumber,
  UserAuthentication,
  SecurityLayer,
  MinEncryptionLevel,
  fEnableWinStation,
  MaxInstanceCount,
  SSLCertificateSHA1Hash

En mi caso era:

PortNumber             : 3389
UserAuthentication     : 0
SecurityLayer          : 2
MinEncryptionLevel     : 2
fEnableWinStation      : 1
MaxInstanceCount       : 4294967295
SSLCertificateSHA1Hash :

A primera vista todo parece casi correcto:

puerto 3389;
WinStation habilitada;
número máximo de sesiones no limitado;
NLA deshabilitado para diagnóstico.

Pero hay un detalle importante:

SecurityLayer : 2
SSLCertificateSHA1Hash : vacío

SecurityLayer = 2 significa que RDP debe usar SSL/TLS. Y SSLCertificateSHA1Hash vacío significa que no hay un bind explícito de certificado.

Usualmente Windows puede crear automáticamente un certificado autofirmado para RDP. Pero si la creación del certificado falla, la parte TLS de RDP también falla.

6. Qué significan SecurityLayer y UserAuthentication

Para entender el diagnóstico es importante saber qué significan los parámetros principales.

SecurityLayer

SecurityLayer = 0

Se usa la antigua capa de seguridad RDP. Es un modo de emergencia y menos seguro. Se puede usar sólo temporalmente para recuperar el acceso.

SecurityLayer = 1

Negotiate. Cliente y servidor negocian el nivel de seguridad disponible. Normalmente es una opción práctica y segura para recuperación.

SecurityLayer = 2

Solo SSL/TLS. El servidor exige TLS. Si el certificado TLS o SChannel está roto, RDP puede dejar de aceptar conexiones por completo.

UserAuthentication

UserAuthentication = 0

NLA deshabilitado.

UserAuthentication = 1

NLA habilitado.

NLA es recomendable en producción, pero durante el diagnóstico se puede desactivar temporalmente para separar el problema de autenticación del problema de transporte/TLS.

7. Comprobación clave: deshabilitar TLS temporalmente

Para entender si el problema es realmente TLS, se puede poner RDP temporalmente en modo de emergencia:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 0
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 1

Restart-Service TermService -Force

Tenga en cuenta: Restart-Service TermService -Force corta todas las sesiones RDP activas. En nuestro escenario nadie puede conectarse de todos modos, así que no hay nada que perder, pero en un servidor “medio vivo” es algo a recordar.

Después comprobamos la conexión:

cmd

mstsc /admin /v:127.0.0.1

O desde otra máquina:

cmd

mstsc /admin /v:<server_ip>

En mi caso, tras deshabilitar TLS, RDP funcionó.

Este es un resultado de diagnóstico vital.

Significa:

el puerto 3389 funciona;
TermService funciona;
el listener rdp-tcp funciona;
los permisos de administrador para iniciar sesión existen;
el problema no está en el firewall;
el problema no está en RemoteApp;
el problema está precisamente en RDP TLS / certificado / SChannel.

8. Confirmación mediante el Visor de eventos

Tras intentos de conexión con TLS en el visor de eventos apareció el error:

Event ID: 1057
Provider: Microsoft-Windows-TerminalServices-RemoteConnectionManager
Level: Error

Al servidor del host de sesiones de Escritorio remoto no se le pudo crear
un nuevo certificado autofirmado para usar al autenticar el servidor del host
de sesiones de Escritorio remoto en las conexiones SSL.

Código de estado: Se especificó un algoritmo incorrecto.

“Se especificó un algoritmo incorrecto” es la descripción textual del error NTE_BAD_ALGID (0x80090008) de la API criptográfica de Windows. Es precisamente este error el que hace que el cliente muestre “Se produjo un error interno” o 0x904 / 0x7.

Ver estos eventos se puede con el comando:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

También es útil revisar los logs de RDP:

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Admin' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

Y SChannel:

powershell
Get-WinEvent -LogName System -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Schannel' -or
    $_.Message -match 'TLS|SSL|certificate|сертификат|handshake'
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

9. Por qué aparece el Event ID 1057

En condiciones normales Windows Server puede crear automáticamente un certificado autofirmado para RDP. Ese certificado se usa para autenticar el servidor en conexiones TLS.

El error 1057 indica que Windows no pudo generar ese certificado autofirmado.

Las causas pueden ser diversas:

el proveedor de criptografía está corrupto o inaccesible;
problema con permisos en MachineKeys;
políticas crypto/FIPS estrictas están activadas;
algoritmos TLS/SChannel necesarios están deshabilitados;
la antigua vinculación del certificado RDP está corrupta;
el certificado fue eliminado, pero Windows no puede crear uno nuevo;
se intentó usar un algoritmo/proveedor no soportado;
se modificaron ajustes mediante herramientas de hardening como IIS Crypto o GPO;
componentes criptográficos del sistema están dañados.

En mi caso la vía de recuperación más rápida y correcta fue no esperar la autogeneración de TermService, sino crear el certificado manualmente y asignarlo explícitamente a RDP-tcp.

10. Antes de corregir: hacer backup

Antes de cambiar la configuración de RDP guardamos la rama del registro actual:

cmd
mkdir C:\Temp 2>nul

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" C:\Temp\RDP-Tcp-backup.reg /y

También guardamos los parámetros actuales:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object `
  PortNumber,
  UserAuthentication,
  SecurityLayer,
  MinEncryptionLevel,
  fEnableWinStation,
  SSLCertificateSHA1Hash |
Out-File C:\Temp\RDP-Tcp-before.txt

11. Comprobamos la política FIPS

El error “Se especificó un algoritmo incorrecto” puede estar relacionado con la política crypto. Comprobamos FIPS:

powershell
Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy' `
  -ErrorAction SilentlyContinue |
Select-Object Enabled

Si:

Enabled : 1

significa que FIPS está habilitado.

También conviene revisar el resultado de las políticas de grupo:

cmd

gpresult /h C:\Temp\gpresult.html

En el informe buscamos:

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

Si el servidor está en dominio y FIPS está activado por GPO, no conviene desactivarlo localmente sin más. Los cambios locales pueden revertirse, y la política puede haberse aplicado por requisitos de seguridad.

12. Comprobamos TLS 1.2 en SChannel

En Windows Server 2019 es normal usar TLS 1.2 para RDP.

Verificamos la configuración TLS:

powershell
$paths = @(
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client',
  'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server'
)

foreach ($path in $paths) {
    Write-Host "`n$path" -ForegroundColor Cyan

    Get-ItemProperty $path -ErrorAction SilentlyContinue |
    Select-Object Enabled, DisabledByDefault
}

Si TLS 1.2\Server existe y allí aparece:

Enabled : 0

DisabledByDefault : 1

TLS 1.2 en el lado servidor está deshabilitado.

Por cierto, tener TLS 1.2 deshabilitado en el servidor suele ser una causa común del error del cliente “Se produjo un error interno”, incluso cuando el certificado está bien: el cliente moderno simplemente no puede negociar el protocolo.

Se puede habilitar TLS 1.2 así:

powershell
$Tls12Server = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
$Tls12Client = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'

New-Item -Path $Tls12Server -Force | Out-Null
New-Item -Path $Tls12Client -Force | Out-Null

New-ItemProperty -Path $Tls12Server -Name Enabled -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Tls12Server -Name DisabledByDefault -Value 0 -PropertyType DWord -Force | Out-Null

New-ItemProperty -Path $Tls12Client -Name Enabled -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $Tls12Client -Name DisabledByDefault -Value 0 -PropertyType DWord -Force | Out-Null

Tras cambiar la configuración de SChannel a menudo se necesita un reinicio. Pero primero se puede restaurar el certificado RDP y comprobar si funciona.

13. Comprobamos permisos en MachineKeys

Windows guarda las claves privadas de máquina aquí:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

Si los permisos de la carpeta están rotos, los servicios no pueden crear o leer claves privadas.

Guardamos las ACL actuales:

cmd
mkdir C:\Temp 2>nul
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c > C:\Temp\MachineKeys-before.txt

Restauración básica de permisos:

cmd
takeown /f "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /a /r

icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "NT AUTHORITY\SYSTEM:(F)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "BUILTIN\Administrators:(F)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c /grant "NT AUTHORITY\NETWORK SERVICE:(R)"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /t /c > C:\Temp\MachineKeys-after.txt

Este es un paso de recuperación. En producción es mejor guardar las ACL originales y entender qué políticas gestionan los permisos.

14. Eliminamos la antigua vinculación TLS de RDP

Eliminamos el hash del certificado antiguo de RDP-Tcp:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Remove-ItemProperty `
  -Path $RdpTcp `
  -Name SSLCertificateSHA1Hash `
  -ErrorAction SilentlyContinue

Eliminamos los certificados autofirmados antiguos de RDP del almacén Remote Desktop:

powershell
Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Remove-Item -Force

Comprobamos qué queda:

powershell
Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Select-Object Subject, Thumbprint, NotAfter

15. Creamos un nuevo certificado manualmente

Punto clave: es mejor crear el certificado explícitamente con RSA/SHA256 y un proveedor crypto compatible.

En mi caso usé:

Microsoft RSA SChannel Cryptographic Provider

Comando:

powershell
$ComputerSystem = Get-CimInstance Win32_ComputerSystem

$DnsNames = @($env:COMPUTERNAME)

if ($ComputerSystem.PartOfDomain) {
    $DnsNames += "$env:COMPUTERNAME.$($ComputerSystem.Domain)"
}

$Cert = New-SelfSignedCertificate `
  -DnsName $DnsNames `
  -CertStoreLocation 'Cert:\LocalMachine\My' `
  -Provider 'Microsoft RSA SChannel Cryptographic Provider' `
  -KeyAlgorithm RSA `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -KeySpec KeyExchange `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -NotAfter (Get-Date).AddYears(3) `
  -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')

$Cert |
Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Hay que asegurarse de que:

HasPrivateKey : True

Sin clave privada ese certificado es inútil para RDP.

Damos a TermService acceso a la clave privada

TermService se ejecuta como NETWORK SERVICE. Si esa cuenta no tiene permiso para leer la clave privada, RDP no podrá usar el certificado — y obtendremos el mismo “error interno” en el cliente, aunque el certificado sea nuevo.

Concedemos permisos al archivo de clave:

powershell
$RsaKey = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($Cert)
$KeyFile = $RsaKey.Key.UniqueName
$KeyPath = Join-Path 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' $KeyFile

icacls $KeyPath /grant 'NT AUTHORITY\NETWORK SERVICE:(R)'

Comprobamos:

powershell
icacls $KeyPath

En la salida debe aparecer la línea con NT AUTHORITY\NETWORK SERVICE:(R).

16. Vinculamos el certificado al listener RDP

Ahora asignamos el certificado a RDP-tcp.

powershell
$RdpSetting = Get-WmiObject `
  -Namespace 'root\cimv2\TerminalServices' `
  -Class 'Win32_TSGeneralSetting' `
  -Filter "TerminalName='RDP-tcp'"

Set-WmiInstance `
  -Path $RdpSetting.__PATH `
  -Arguments @{ SSLCertificateSHA1Hash = $Cert.Thumbprint }

Comprobamos:

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

También comprobamos el registro:

powershell
Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
Select-Object SSLCertificateSHA1Hash

El valor debería dejar de estar vacío.

17. Sacamos RDP del modo de emergencia

No conviene devolver inmediatamente el TLS forzado SecurityLayer = 2.

Primero ponemos una opción intermedia segura:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 1
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 2
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0

Restart-Service TermService -Force

Comprobamos localmente:

cmd

mstsc /admin /v:127.0.0.1

Comprobamos desde fuera:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

Si funciona — devolvemos NLA:

powershell
Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication `
  -Value 1

Restart-Service TermService -Force

Comprobamos de nuevo:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

18. ¿Se puede volver a SecurityLayer = 2?

Si se desea forzar TLS, tras la comprobación exitosa con SecurityLayer = 1 se puede intentar:

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 2
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 3
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 1

Restart-Service TermService -Force

Comprobamos:

cmd

mstsc /admin /v:<server_ip_or_fqdn>

Si con SecurityLayer = 1 todo funciona y con SecurityLayer = 2 vuelve a romperse, significa que el problema con TLS/SChannel/política de certificados no se ha eliminado por completo.

En tal caso es mejor dejar temporalmente:

SecurityLayer = 1
UserAuthentication = 1
MinEncryptionLevel = 2 o 3

Esto es mucho mejor que el modo de emergencia:

SecurityLayer = 0

19. Comprobamos si desapareció el error 1057

Tras restaurar el certificado y reiniciar TermService comprobamos el registro:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 100 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

Si no hay nuevos eventos 1057 tras el reinicio, es una buena señal.

También se pueden revisar eventos relacionados:

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 100 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -in 1056,1057,1058
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

20. Revisamos las políticas RDP por GPO

Si el servidor está en dominio, la configuración puede venir por políticas.

Generamos un informe:

cmd

gpresult /h C:\Temp\gpresult.html

En el informe buscamos:

Computer Configuration
  Administrative Templates
    Windows Components
      Remote Desktop Services
        Remote Desktop Session Host
          Security

Particularmente importantes son las políticas:

Require use of specific security layer for remote (RDP) connections
Require user authentication for remote connections by using Network Level Authentication
Set client connection encryption level
Server authentication certificate template

También comprobamos la parte de registro de las políticas:

powershell
Get-ItemProperty `
  'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' `
  -ErrorAction SilentlyContinue |
Select-Object SecurityLayer, UserAuthentication, MinEncryptionLevel, SSLCertificateSHA1Hash

Si allí aparece algo como:

SecurityLayer : 2

los cambios locales pueden revertirse tras un gpupdate.

21. Qué hacer con RemoteApp y RDWeb tras restaurar RDP

Después de que RDP normal funcione, se puede volver a RemoteApp.

En mi caso W3SVC estaba detenido y deshabilitado:

W3SVC  Stopped  Disabled

Para RD Web Access eso es un problema.

Habilitamos IIS:

powershell
Set-Service W3SVC -StartupType Automatic
Start-Service W3SVC

Comprobamos:

powershell
Get-Service W3SVC

Comprobamos la disponibilidad de RDWeb:

https://<server_fqdn>/RDWeb

Si se usa RD Gateway, comprobamos:

powershell
Get-Service TSGateway -ErrorAction SilentlyContinue

Y los logs:

powershell
Get-WinEvent `
  -LogName 'Microsoft-Windows-TerminalServices-Gateway/Operational' `
  -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

Comprobamos el despliegue RDS:

powershell
Import-Module RemoteDesktop

Get-RDServer
Get-RDSessionCollection
Get-RDRemoteApp

Revisamos permisos en las colecciones:

powershell
Get-RDSessionCollection | ForEach-Object {
    Write-Host "`nCollection: $($_.CollectionName)" -ForegroundColor Cyan

    Get-RDSessionCollectionConfiguration `
      -CollectionName $_.CollectionName `
      -UserGroup
}

22. Checklist mínimo de recuperación

Si necesita restaurar el acceso rápido, el orden es el siguiente.

1. Comprobar el listener

cmd

qwinsta
change logon /query

Debe mostrarse:

rdp-tcp  Escucha
Iniciar sesión desde sesiones ahora está ACTIVADO

2. Comprobar parámetros RDP

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Get-ItemProperty $RdpTcp |
Select-Object PortNumber, UserAuthentication, SecurityLayer, MinEncryptionLevel, fEnableWinStation, SSLCertificateSHA1Hash

3. Si necesita entrar urgentemente — deshabilitar TLS temporalmente

powershell
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 0
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 1

Restart-Service TermService -Force

Comprobar:

cmd

mstsc /admin /v:<server_ip>

4. Comprobar Event ID 1057

powershell
Get-WinEvent `
  -LogName System `
  -MaxEvents 200 |
Where-Object {
    $_.ProviderName -eq 'Microsoft-Windows-TerminalServices-RemoteConnectionManager' -and
    $_.Id -eq 1057
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

5. Crear y vincular un nuevo certificado RSA/SHA256

powershell
$RdpTcp = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

Remove-ItemProperty `
  -Path $RdpTcp `
  -Name SSLCertificateSHA1Hash `
  -ErrorAction SilentlyContinue

Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' -ErrorAction SilentlyContinue |
Remove-Item -Force

$ComputerSystem = Get-CimInstance Win32_ComputerSystem
$DnsNames = @($env:COMPUTERNAME)

if ($ComputerSystem.PartOfDomain) {
    $DnsNames += "$env:COMPUTERNAME.$($ComputerSystem.Domain)"
}

$Cert = New-SelfSignedCertificate `
  -DnsName $DnsNames `
  -CertStoreLocation 'Cert:\LocalMachine\My' `
  -Provider 'Microsoft RSA SChannel Cryptographic Provider' `
  -KeyAlgorithm RSA `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -KeySpec KeyExchange `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -NotAfter (Get-Date).AddYears(3) `
  -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')

$RsaKey = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($Cert)
$KeyPath = Join-Path 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' $RsaKey.Key.UniqueName
icacls $KeyPath /grant 'NT AUTHORITY\NETWORK SERVICE:(R)'

$RdpSetting = Get-WmiObject `
  -Namespace 'root\cimv2\TerminalServices' `
  -Class 'Win32_TSGeneralSetting' `
  -Filter "TerminalName='RDP-tcp'"

Set-WmiInstance `
  -Path $RdpSetting.__PATH `
  -Arguments @{ SSLCertificateSHA1Hash = $Cert.Thumbprint }

6. Volver al modo normal

powershell
Set-ItemProperty -Path $RdpTcp -Name SecurityLayer -Value 1
Set-ItemProperty -Path $RdpTcp -Name MinEncryptionLevel -Value 2
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 0

Restart-Service TermService -Force

Comprobar:

cmd

mstsc /admin /v:<server_ip>

Si funciona — restaurar NLA:

powershell
Set-ItemProperty -Path $RdpTcp -Name UserAuthentication -Value 1

Restart-Service TermService -Force

23. Qué no hacer

No dejar SecurityLayer = 0

Es un modo de emergencia. Ayudó a demostrar que el problema era TLS, pero no es adecuado para uso permanente.

No empezar por reinstalar RDS

Si rdp-tcp escucha y RDP revive sin TLS, reinstalar RDS casi seguro es innecesario.

No intentar arreglar RemoteApp mientras mstsc normal no funcione

RemoteApp depende del RDP. Si el RDP básico no funciona, diagnosticar RemoteApp será ruidoso y poco eficaz.

No ignorar las GPO

Si las configuraciones de seguridad vienen de la política de dominio, los cambios locales pueden revertirse.

No eliminar certificados a ciegas sin entender

Eliminar el certificado autofirmado de RDP suele ser aceptable, pero si estaba asignado un certificado corporativo, habrá que volver a asignarlo.

24. Por qué funcionó esta solución

El diagnóstico mostró:

Puerto 3389 abierto
TermService iniciado
rdp-tcp escucha
Inicios de sesión permitidos
RDP sin TLS funciona
RDP con TLS no funciona
Event ID 1057: TermService no puede crear certificado autofirmado

Así que el problema no estaba en la red, ni en el firewall, ni en los permisos de administrador.

La raíz del problema estaba en la cadena:

TermService → certificado RDP TLS → SChannel / proveedor crypto → handshake TLS

Crear manualmente un certificado RSA/SHA256 y asignarlo explícitamente a RDP-tcp elimina la dependencia de la autogeneración de certificados, que estaba rota.

Después de eso se pueden restaurar los parámetros de seguridad normales:

SecurityLayer = 1
UserAuthentication = 1

Y solo después ocuparse de RemoteApp, RDWeb, RD Gateway y las colecciones RDS.

25. Conclusión

Si en Windows Server 2019 dejó de funcionar RDP pero el puerto 3389 está abierto, no basta con comprobar el firewall. Un puerto TCP abierto no significa que RDP pase correctamente TLS/NLA/CredSSP.

Desde el lado del cliente esta falla aparece como “Se produjo un error interno” (An internal error has occurred) o como el código de error 0x904 con código ampliado 0x7. Intentar desentrañar esos códigos del cliente es inútil — la causa está en el servidor.

En mi caso la clave del diagnóstico fue la comparación:

SecurityLayer = 2  → RDP no funciona
SecurityLayer = 0  → RDP funciona

Y la confirmación en el Visor de eventos:

Event ID 1057
No se pudo crear un nuevo certificado autofirmado
Código de estado: Se especificó un algoritmo incorrecto

Tratamiento adecuado:

restaurar temporalmente el acceso con SecurityLayer = 0;
no dejar este modo permanentemente;
eliminar la antigua vinculación TLS de RDP;
crear un nuevo certificado RSA/SHA256;
dar a NETWORK SERVICE acceso a su clave privada;
asignar explícitamente el certificado a RDP-tcp;
volver a SecurityLayer = 1;
restaurar NLA;
revisar GPO y SChannel;
tras restaurar el RDP básico, arreglar RDWeb/RemoteApp.

Idea principal: RemoteApp no se puede diagnosticar mientras no funcione el RDP normal. Primero hay que levantar el listener RDP básico con TLS correcto y solo entonces abordar las capas superiores de RDS.

Etiquetas:

#windows-server #rdp #remoteapp #tls #schannel #certificados #resolucion-de-problemas #seguridad #devops

¿Te ayudó? Apóyame Apóyame en Boosty

// Reviews

Reseñas relacionadas

Llegué con una solicitud costosa para la configuración de un servidor VPS, pero durante la consulta Mikhail propuso una solución mucho más sencilla y económica. Al final ahorré dinero y tiempo. Mikhail — un verdadero experto que trabaja por el resultado del cliente, no por la factura. ¡Lo recomiendo!

Llegué con una solicitud costosa para la configuración de un servidor VPS, pero durante la consulta Mikhail propuso una solución mucho más simple y económica. Al final ahorré presupuesto y tiempo. Mikhail es un …

kfhzasorin