Problema

En entornos de Azure con Windows Server, es frecuente que los administradores intenten conectarse mediante Remote Desktop Protocol (RDP) y encuentren el evento 1057 en el visor de eventos del servidor. El mensaje indica que el RD Session Host Server no pudo crear un nuevo certificado auto‑firmado para la autenticación SSL y que el código de estado asociado es Object already exists. El síntoma inmediato es la imposibilidad de establecer una sesión RDP, aunque la VM esté encendida y la red parezca operativa.

Este patrón no está limitado a una versión concreta de Windows ni a una configuración particular de Azure; cualquier despliegue que dependa del servicio de Remote Desktop Services (RDS) y que tenga problemas al generar o registrar el certificado auto‑firmado puede presentar el mismo error.

Causa

El error 1057 suele originarse por una de las siguientes situaciones:

  1. Colisión en el almacén de certificados – Un certificado con el mismo thumbprint o subject ya existe en el almacén Remote Desktop y el proceso de creación falla al intentar sobrescribirlo.
  2. Permisos insuficientes – La cuenta del servicio TermService (o el contexto del proceso svchost.exe que ejecuta RDS) no tiene derechos de escritura en el almacén de certificados del equipo.
  3. Política de grupo que bloquea la generación automática – Algunas GPO restringen la creación de certificados auto‑firmados o imponen un algoritmo de firma no soportado por la versión del servidor.
  4. Corrupción del almacén de certificados – Entradas huérfanas o claves rotas pueden impedir que el servicio registre un nuevo certificado.
  5. Actualizaciones de Windows que modifican la lógica de generación – En ciertos parches, el método interno para crear el certificado cambia y, si el almacén está en un estado inesperado, el proceso falla.

En la práctica, la causa más frecuente es la colisión: el certificado anterior no se eliminó correctamente después de una reinstalación de RDS o de una restauración de la VM.

Solución

La estrategia consiste en limpiar el almacén de certificados, verificar permisos y, si es necesario, forzar la creación manual de un certificado auto‑firmado que cumpla con los requisitos de RDS. Los pasos son reutilizables en cualquier VM de Azure (o on‑premise) que presente el mismo error.

1. Eliminar el certificado conflictivo

  1. Abrir una sesión PowerShell con privilegios de administrador.
  2. Listar los certificados bajo la ruta Remote Desktop:
Get-ChildItem -Path Cert:\LocalMachine\RemoteDesktop
  1. Identificar el certificado cuyo Subject sea CN=Remote Desktop o cuyo FriendlyName sea Remote Desktop y eliminarlo:
Get-ChildItem -Path Cert:\LocalMachine\RemoteDesktop |
Where-Object { $_.Subject -like "*Remote Desktop*" } |
Remove-Item

2. Asegurar permisos del servicio

El proceso TermService necesita acceso de escritura al almacén. Ejecutar:

$acl = Get-Acl -Path Cert:\LocalMachine\RemoteDesktop
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT SERVICE\TermService","FullControl","Allow")
$acl.SetAccessRule($rule)
Set-Acl -Path Cert:\LocalMachine\RemoteDesktop -AclObject $acl

Esto otorga los derechos necesarios sin abrir el almacén a usuarios no deseados.

3. Generar un certificado auto‑firmado válido

Si el paso anterior no dispara la creación automática, generar manualmente:

$cert = New-SelfSignedCertificate -DnsName $env:COMPUTERNAME `
    -CertStoreLocation "Cert:\LocalMachine\RemoteDesktop" `
    -KeyExportPolicy Exportable `
    -Provider "Microsoft RSA SChannel Cryptographic Provider" `
    -HashAlgorithm SHA256 `
    -NotAfter (Get-Date).AddYears(5) `
    -FriendlyName "Remote Desktop"

Una vez creado, enlazarlo al listener RDP:

# Obtener el ID del listener
$listener = (Get-Item "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").GetValue("SSLCertificateSHA1Hash")
# Reemplazar con el thumbprint del nuevo certificado
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
    -Name "SSLCertificateSHA1Hash" -Value $cert.Thumbprint

4. Reiniciar el servicio RDS

Restart-Service -Name TermService -Force

5. (Opcional) Desactivar temporalmente la política de generación automática

Si una GPO está bloqueando la creación, localizar la política Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → Require use of specific security layer for remote (RDP) connections y configurarla en Not Configured o Disabled mientras se realiza la reparación.

Cuándo aplicar esta solución

  • Síntomas: Evento 1057 en el visor, error “Object already exists” al iniciar RDP, incapacidad para conectarse aunque el puerto 3389 esté abierto.
  • Entorno: Windows Server (cualquier versión) ejecutándose en Azure VM o en infraestructura local, con RDS habilitado.
  • Exclusiones: Si el error proviene de una falla de red (p. ej., NSG bloqueando 3389) o de una licencia de RDS vencida, la solución de certificado no será efectiva.

Código

# 1. Listar y eliminar certificado conflictivo
Get-ChildItem -Path Cert:\LocalMachine\RemoteDesktop |
Where-Object { $_.Subject -like "*Remote Desktop*" } |
Remove-Item

# 2. Conceder permisos a TermService
$acl = Get-Acl -Path Cert:\LocalMachine\RemoteDesktop
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT SERVICE\TermService","FullControl","Allow")
$acl.SetAccessRule($rule)
Set-Acl -Path Cert:\LocalMachine\RemoteDesktop -AclObject $acl

# 3. Crear certificado auto‑firmado
$cert = New-SelfSignedCertificate -DnsName $env:COMPUTERNAME `
    -CertStoreLocation "Cert:\LocalMachine\RemoteDesktop" `
    -KeyExportPolicy Exportable `
    -Provider "Microsoft RSA SChannel Cryptographic Provider" `
    -HashAlgorithm SHA256 `
    -NotAfter (Get-Date).AddYears(5) `
    -FriendlyName "Remote Desktop"

# 4. Vincular al listener RDP
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
    -Name "SSLCertificateSHA1Hash" -Value $cert.Thumbprint

# 5. Reiniciar servicio RDS
Restart-Service -Name TermService -Force

Verificación

  1. Abrir el Visor de Eventos → Applications and Services Logs → Microsoft → Windows → TerminalServices‑RemoteConnectionManager → Operational. Confirmar que el evento 1057 ya no aparece.
  2. Ejecutar qwinsta desde una máquina cliente para comprobar que la sesión RDP responde.
  3. Intentar conectar con el cliente de escritorio remoto; la autenticación SSL debe completarse sin advertencias de certificado.
  4. Verificar que el certificado aparece en certmgr.msc bajo Remote Desktop con el FriendlyName “Remote Desktop”.

Notas adicionales

  • En entornos con Azure Bastion, el tráfico RDP no pasa por el puerto 3389 directamente; sin embargo, el mismo almacén de certificados se usa para la capa TLS interna, por lo que el procedimiento sigue siendo válido.
  • Si la VM está protegida por Azure Policy que impide la creación de certificados, será necesario ajustar la política o crear el certificado fuera de la VM y luego importarlo con Import-PfxCertificate.
  • Mantener una copia de seguridad del almacén de certificados (certutil -store RemoteDesktop > backup.txt) antes de eliminar entradas facilita la recuperación en caso de error inesperado.
  • Después de aplicar la solución, es buena práctica crear una tarea programada que verifique la existencia del certificado cada 24 h y lo regenere automáticamente si falta. Esto evita que el problema reaparezca tras actualizaciones de Windows.