RD Gateway error 0x00000904 and 0x00000103: tunnel dies before the desktop

Fix it now

These are gateway failures reported by the Remote Desktop client, and they describe a tunnel that could not be established rather than a desktop that could not start. In most deployments the cause is the certificate: the name on it, the chain behind it, or the name the client was told to dial.

Test-NetConnection gateway.example.com -Port 443
netsh http show sslcert

1. Note the exact gateway name the client uses. In the Remote Desktop client open Show Options, Advanced, Settings and read the gateway server name, or open the .rdp file in Notepad and read the gateway host name line.
2. Browse to https://gateway.example.com/RDWeb from the same client and inspect the certificate. The name you dialled must appear in the subject or the subject alternative names, the dates must be current, and the chain must resolve.
3. On the gateway, compare the hash from netsh http show sslcert with the thumbprint of the certificate you meant to use. A renewed certificate that was never rebound is the single most common cause of this appearing overnight.
4. On the client, open certlm.msc and confirm the issuing authority’s root, and any intermediate, are present and trusted.

The error arrives in a second or two rather than after a timeout. That is a decision, not a wait, and it tells you the certificate was evaluated and rejected rather than the traffic being dropped somewhere in the path.

If the tunnel opens, stop here. If the certificate looks correct in a browser and the client still fails, the next section covers the third name in play and the protocol floor underneath it.

Why it happens

An RD Gateway connection is RDP carried inside HTTPS. Before a byte of RDP is exchanged, the client opens a TLS connection on port 443 and checks the certificate offered: that it is in date, that its chain leads to a root the client already trusts, and that the name typed appears on it. Any one of those failing ends the connection there. That is why the error is instant, why nothing appears in the session host logs, and why the gateway’s own policies are irrelevant to it.

The name check catches most deployments, because there are usually two names in play and sometimes three. Internally the gateway is known by its domain name; remote users dial a public one. If the certificate carries only one of them, half your users work. The name embedded in the .rdp file that RD Web Access hands out is a third value, and it can drift out of step with both without anyone touching the certificate.

The trust check catches the rest. A certificate from an internal certification authority is trusted automatically by domain-joined machines, because the root arrives through Group Policy, and by nothing else. Home computers, personal tablets and contractor laptops see an unknown issuer and refuse the tunnel. A missing intermediate does the same thing, because Remote Desktop clients are far less forgiving than browsers about fetching what the server did not send.

Microsoft publishes what an RDS certificate has to be rather than what these client error numbers mean. The requirements are worth knowing because they are a checklist you can run against the certificate in front of you: issued for Server Authentication, issued by an authority trusted by both the servers and the clients, and imported with an exportable private key.

Full reference

Matching the symptom to the layer

What the certificate has to be

• Issued for Server Authentication.
• Issued by a certification authority trusted by the RDS servers and by the clients. For unmanaged devices that means a public authority, because there is nothing to distribute a root through.
• Imported with an exportable private key, and held in the local computer Personal store on the gateway.
• Carrying every name any client might dial, in the subject or the subject alternative names.
• In date, with a renewal process that rebinds as well as reissues.

Assigning it once, for the whole deployment

On a full RDS deployment, assign certificates at Server Manager, Remote Desktop Services, Overview, Deployment Overview, TASKS, Edit Deployment Properties, Certificates. That page covers the gateway, the web access role and the broker together, which is what stops the three drifting apart. Server Manager can also add the certificate to the Trusted Root Certification Authorities store on the destination computers as part of the same operation, which is useful inside the deployment and does nothing for external clients.

Reading the binding rather than the store

netsh http show sslcert
netsh http show iplisten
netsh http show urlacl

The certificate store shows what is installed; the HTTP.sys binding table shows what is actually being served. A perfectly valid certificate that is not the one bound to the endpoint produces exactly the failure on this page, and no amount of inspecting the store will reveal it. Compare the hash in the binding with the thumbprint you expect, every time.

When it is not the certificate

1. Confirm something is listening: Test-NetConnection gateway.example.com -Port 443 from outside your network.
2. Confirm the name resolves to the address you expect from outside, not just from inside. Split DNS is a common surprise.
3. Confirm the client is not being intercepted. A TLS-inspecting proxy in the path substitutes its own certificate, which a Remote Desktop client will refuse even when a browser accepts it.
4. If the tunnel opens and the refusal comes afterwards, you have an authorisation problem rather than a certificate one, and the gateway policy logs will say so.
5. If nothing accepts the connection at all, the listener itself never came up, which is a binding problem on the gateway rather than a trust problem on the client.

What a certificate purchase does and does not buy

A certificate from a publicly trusted authority is the least effort where unmanaged devices connect, because there is nothing to distribute. Where every client is domain-joined, one from your own certification authority works identically and costs nothing, because the root is already in place through Group Policy. Neither route involves a Windows or RDS licence, and a self-signed certificate is a placeholder rather than an option: it works only where you have installed that exact certificate into the trusted roots of every client, which stops being manageable past a handful of machines.

Every code this article covers

Confirm the fix worked

1. A client outside your network connects and the session opens with no certificate prompt.
2. The certificate the gateway presents carries the name that client dialled, in date, with a chain that resolves on an unmanaged machine.
3. netsh http show sslcert on the gateway shows a bound hash matching the intended certificate.
4. The gateway name in a freshly downloaded .rdp file matches a name on the certificate.
5. A domain-joined client and an unmanaged client both connect, so you have tested both trust paths.

Questions people ask about this