Error Message 0x80090304 when using remote desktop

Understanding Error 0x80090304 in Remote Desktop

Error 0x80090304 is a security-related error that occurs during the TLS/SSL handshake when establishing a Remote Desktop Protocol (RDP) connection, either directly or through a Terminal Services (TS) Gateway. The error indicates that the security package on the client side could not establish a secure connection with the server.

The full error message typically reads:

An error was encountered when trying to connect to the Remote Desktop Gateway server.
Error code: 0x80090304

This error can appear suddenly on connections that were previously working fine, often after a Windows Update, certificate renewal, or Group Policy change.

Common Causes

1. TLS/SSL Version Mismatch

The RDP client and the server (or TS Gateway) must agree on a TLS protocol version. If the server requires TLS 1.2 but the client only supports TLS 1.0, or vice versa, the handshake will fail with 0x80090304.

2. Expired or Invalid SSL Certificate

The TS Gateway server uses an SSL certificate to authenticate itself to clients. If this certificate is expired, revoked, self-signed without proper trust chain, or has a subject name that does not match the server hostname, the connection will fail.

3. Network Level Authentication (NLA) Issues

NLA requires the client to authenticate before a full RDP session is established. Mismatched NLA settings or missing CredSSP support can trigger this error.

4. CredSSP Encryption Oracle Remediation

Starting with the March 2018 security update for CVE-2018-0886, Microsoft changed how the Credential Seguridad Support Provider (CredSSP) handles authentication. If the client has the update but the server does not (or the Group Policy is set to “Force Updated Clients”), connections will be refused.

5. Cipher Suite Incompatibility

If the server’s configured cipher suites do not overlap with those supported by the client, TLS negotiation will fail.

Diagnosing the Issue

Check the Event Logs on the Server

On the TS Gateway or RDP host server, open Event Viewer and check:

• Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational
• System log for Schannel errors (Event ID 36887 or 36871)

Look for entries like:

A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.

Alert code 40 indicates a handshake failure.

Verify the SSL Certificate

On the TS Gateway server:

1. Open Remote Desktop Gateway Manager (tsgateway.msc)
2. Right-click the server name and select Properties
3. Go to the SSL Certificate tab
4. Verify the certificate is valid, not expired, and the subject name matches the FQDN clients use to connect

You can also check the certificate from the command line:

Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*gateway*" } | Format-List Subject, NotAfter, Thumbprint

Test TLS Connectivity

From the client machine, test whether TLS is working to the gateway server:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$tcp = New-Object Net.Sockets.TcpClient("gateway.example.com", 443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream())
$ssl.AuthenticateAsClient("gateway.example.com")
$ssl.SslProtocol
$ssl.Dispose()
$tcp.Dispose()

If this fails, the TLS handshake is the problem.

Fix 1: Ensure TLS 1.2 Is Enabled on Both Sides

On the Server

Open Registry Editor and verify these keys exist and are set correctly:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
    "Enabled" = dword:00000001
    "DisabledByDefault" = dword:00000000

On the Client

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
    "Enabled" = dword:00000001
    "DisabledByDefault" = dword:00000000

After making registry changes, restart the server/client.

Fix 2: Update or Replace the SSL Certificate

If the certificate is expired or mismatched:

1. Obtain a new SSL certificate from your CA with a Subject Alternative Name (SAN) matching the gateway’s FQDN
2. Install the certificate in the Local Computer > Personal certificate store
3. Open Remote Desktop Gateway Manager and assign the new certificate
4. Restart the Remote Desktop Gateway service:

Restart-Service -Name TSGateway

Fix 3: Configure CredSSP Policy

If the error started after a Windows Update, the CredSSP remediation policy may be the cause.

Via Group Policy

1. Open gpedit.msc on the client machine
2. Navigate to Computer Configuración > Administrative Templates > System > Credentials Delegation
3. Open Encryption Oracle Remediation
4. Set it to Enabled and choose the protection level:

Setting	Behavior
Force Updated Clients	Only connects to patched servers (most secure)
Mitigated	Blocks connections to unpatched servers but allows from unpatched clients
Vulnerable	Allows all connections (least secure, use temporarily only)

Via Registry (If Group Policy Is Not Available)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002

The value 2 corresponds to Vulnerable (allows all connections). Use this only as a temporary fix while you patch the server.

# PowerShell equivalent
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" -Name "AllowEncryptionOracle" -Value 2 -PropertyType DWord -Force

Fix 4: Adjust Network Level Authentication (NLA)

If NLA is causing the issue, you can temporarily disable it on the server:

1. Open System Properties on the RDP host
2. Go to the Remote tab
3. Uncheck Allow connections only from computers running Remote Desktop with Network Level Authentication

Or via Group Policy:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
    "Require user authentication for remote connections by using NLA" = Disabled

To configure NLA via registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"UserAuthentication"=dword:00000000

Fix 5: Verify Credential Delegation Settings

If you are using credential delegation (passing credentials through the TS Gateway to the backend RDP host), ensure it is properly configured:

1. Open gpedit.msc on the client
2. Navigate to Computer Configuración > Administrative Templates > System > Credentials Delegation
3. Enable Allow delegating default credentials and add the server:

TERMSRV/gateway.example.com
TERMSRV/*.example.com

4. Also enable Allow delegating default credentials with NTLM-only server authentication if the server is not using Kerberos

Fix 6: Reset the Schannel Cache

Sometimes the TLS session cache becomes corrupted. Restart the server or clear the cache:

# Restart the RDP-related services
Restart-Service -Name TermService -Force
Restart-Service -Name TSGateway -Force

On the client side, clearing the RDP connection cache can help:

# Remove cached RDP credentials
cmdkey /list | Select-String "TERMSRV" | ForEach-Object {
    $target = ($_ -split "\s+")[-1]
    cmdkey /delete:$target
}

Prevention and Mejores Prácticas

1. Keep both clients and servers patched to the same CredSSP level to avoid oracle remediation conflicts
2. Monitor SSL certificate expiration and renew certificates before they expire
3. Standardize on TLS 1.2 or higher across all RDP infrastructure
4. Use certificates from a trusted CA rather than self-signed certificates
5. Test connectivity after every Windows Update cycle, especially security updates that affect Schannel or CredSSP
6. Document your TS Gateway configuration including certificate thumbprints, TLS settings, and Group Policy assignments

Resumen

Error 0x80090304 during Remote Desktop or Terminal Services Gateway connections is a TLS/SSL handshake failure. The most common causes are expired certificates, TLS version mismatches, and CredSSP policy conflicts introduced by Windows security updates. Check the SSL certificate on the gateway server first, ensure TLS 1.2 is enabled on both endpoints, and verify that CredSSP encryption oracle remediation policies are consistent between client and server.