Event ID 1057: RD Session Host cannot create its self-signed RDP certificate

Fix it now

The Session Host has no usable certificate for its RDP listener, so Schannel cannot build a TLS credential and clients fail during the handshake. Delete the RDP self-signed certificate from the Remote Desktop store and restart Remote Desktop Services; the service creates a fresh certificate and key on start.

Get-CimInstance -Namespace root\CIMV2\TerminalServices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'" | Select-Object SSLCertificateSHA1Hash
Restart-Service TermService -Force

1. Open certlm.msc on the host. Expand Remote Desktop, then Certificates, and delete the RDP self-signed certificate. That store is rebuilt by the service, which is why deleting from it is safe and deleting from Personal is not.
2. Restart Remote Desktop Services (the second command above), refresh the snap-in, and confirm exactly one new certificate has appeared with a current validity range.
3. If nothing is regenerated, look at the permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Microsoft’s documented state is BUILTIN\Administrators with Full control and Everyone with Read and Write.
4. Run the first command again and check the hash it returns matches the thumbprint of the new certificate. A hash that points at nothing is a listener with no credential to offer.

Microsoft does not publish a meaning for Event ID 1057 or for the Schannel ids that accompany it. What is documented is this repair path for a host with no usable RDP listener certificate, which is the condition those entries appear against.

If clients connect again you can stop here. If the certificate will not regenerate, or it regenerates and the handshake still fails, the next section separates the certificate faults from the protocol ones.

Why it happens

Every RDP connection begins with TLS. Before a keystroke is exchanged, the Session Host has to present a server certificate and prove it holds the matching private key. Where no certificate has been assigned by policy or by a deployment, Remote Desktop Services generates a self-signed one for itself, writes the private key into the machine key store, and records the certificate’s thumbprint against the RDP-Tcp listener in the registry. Schannel builds the server credential from that pair on every inbound connection.

Three separate things therefore have to be intact at once: the certificate in the Remote Desktop store, the private key on disk under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and the thumbprint recorded under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Break any one and the listener has nothing to offer. The failure is silent from the client’s side: no logon prompt, no useful message, just a connection that ends.

Reading the Schannel entries alongside the Remote Desktop ones is what tells you which half of the problem you have. Entries about a credential that could not be created point at the certificate or its key, because the server never got as far as offering anything. Entries about a fatal alert during a handshake mean the server did build a credential and the client refused it, which is a protocol or cipher disagreement and has nothing to do with the certificate at all. Microsoft does not publish those event numbers, so read what each entry says rather than trusting a number you looked up.

Full reference

Where each piece of the credential lives

Microsoft’s documented repair is deliberately short: delete the RDP self-signed certificate from the Remote Desktop folder, restart Remote Desktop Services, refresh, and if nothing was recreated go and look at the MachineKeys permissions. Everything else on this page is what to do when that sequence does not produce a certificate.

Reading the state of the listener from the command line

Get-CimInstance -Namespace root\CIMV2\TerminalServices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'" | Select-Object TerminalName, SSLCertificateSHA1Hash, SecurityLayer, MinEncryptionLevel

SSLCertificateSHA1Hash is the thumbprint the listener will look for. An empty value means no certificate has been assigned and the service should be generating one; a value with no matching certificate anywhere on the machine is the stale-thumbprint case. This is the same WMI class Microsoft documents for assigning a certificate to the listener by thumbprint, so it is the authoritative place to read the current state.

Restarting the service without surprising anyone

• Restarting Remote Desktop Services ends every session on that host. On a farm, drain the host first so the broker stops sending people to it, and let existing sessions finish.
• Do the restart from the physical or virtual console, or from an out-of-band management path. Restarting the service you are connected through works, but you lose the session mid-way and cannot see the result.
• On a standalone server with nobody on it, a reboot is simpler and rules out a half-restarted dependency at the same time.
• Take a copy of the RDP-Tcp registry key before you delete any value from it. It is small, and exporting it costs nothing.

When the certificate rebuilds and connections still fail

At that point you are no longer looking at a certificate problem, whatever the event log says. Work down this list before you touch the certificate again.

1. Confirm the listener is on the port clients are dialling. PortNumber under the WinStations key is 3389 unless someone changed it.
2. Confirm fDenyTSConnections under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server is 0. A 1 there refuses connections regardless of the certificate.
3. Confirm both Remote Desktop Services (TermService) and the Remote Desktop Services UserMode Port Redirector (UmRdpService) are running.
4. Test from a client on the same subnet as the host, to take the network out of the question.
5. If only remote users fail, look at the gateway rather than the host: a gateway certificate fault produces its own errors and never reaches this listener.

What a purchased certificate does and does not do

Nothing on this page needs a purchase. The self-signed certificate the Session Host generates is a working TLS credential and connections succeed with it. What it does not do is chain to anything a client already trusts, so users see a warning about the identity of the remote computer the first time they connect to each host. A certificate from a certification authority the clients trust removes that warning. It has no effect at all on a host that cannot create a credential in the first place, which is what this article is about, so fix the listener first and treat the trust warning as a separate piece of work.

If you do go that way, the requirements Microsoft publishes for Remote Desktop Services certificates apply: issued for Server Authentication, issued by an authority trusted by both the servers and the clients, and imported with an exportable private key. On a full deployment, assign it through Server Manager, Remote Desktop Services, Overview, TASKS, Edit Deployment Properties, Certificates, so every role in the deployment gets the same one.

Every code this article covers

Confirm the fix worked

1. Exactly one certificate exists in the local computer Remote Desktop store, with a validity range that includes today.
2. SSLCertificateSHA1Hash from the WMI query matches that certificate’s thumbprint.
3. A client connects and reaches a logon prompt without a handshake failure.
4. The permissions on the MachineKeys folder match the documented state: BUILTIN\Administrators Full control, Everyone Read and Write.
5. After a reboot of the host, the same certificate is still bound and no new Remote Desktop or Schannel failures appear.

Questions people ask about this