Introduction to TLS/SSL for Remote Desktop Protocol
Remote Desktop Protocol (RDP) is one of the most widely used management interfaces in Windows Server environments, and it is also one of the most frequently targeted services by attackers. Securing RDP with proper TLS/SSL configuration on Windows Server 2022 is not optional — it is a fundamental security requirement. By default, Windows Server 2022 supports multiple security layers for RDP connections, but the defaults are not always as strict as enterprise security policies demand. This article walks through the full configuration of TLS for RDP, including enforcing TLS 1.2, replacing self-signed certificates with CA-issued certificates, enabling Network Level Authentication, tuning cipher suites, and validating the configuration with external tools.
Understanding RDP Security Layers
RDP supports three security layers: RDP Security (classic encryption using RSA RC4, now deprecated), SSL/TLS (the modern standard), and Negotiate (server picks the best supported by the client). Windows Server 2022 defaults to Negotiate, which means a client that does not support TLS could still connect using the legacy RDP Security layer. To eliminate this risk, you should force SSL/TLS as the only accepted security layer.
The security layer is configured through Group Policy. Navigate to:
Computer Configuration > Administrative Templates > Windows Components
> Remote Desktop Services > Remote Desktop Session Host > Security
Setting: Require use of specific security layer for remote connections
Value: SSLThis forces all RDP connections to use TLS. Any client that cannot negotiate TLS will be refused. You can also set this via registry:
HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
Value: SecurityLayer
Type: DWORD
Data: 2 (0=RDP, 1=Negotiate, 2=SSL/TLS)Enforcing TLS 1.2 via SCHANNEL Registry Settings
Windows Server 2022 ships with TLS 1.3 support, but many organizations need to ensure TLS 1.2 is the minimum allowed version and that TLS 1.0 and TLS 1.1 are explicitly disabled. The SCHANNEL provider in Windows controls all TLS/SSL behavior at the OS level, and its configuration lives in the registry under:
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTo disable TLS 1.0 for both client and server roles, create the following registry keys:
# Disable TLS 1.0 Server
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server" /v DisabledByDefault /t REG_DWORD /d 1 /f
# Disable TLS 1.0 Client
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client" /v DisabledByDefault /t REG_DWORD /d 1 /f
# Disable TLS 1.1 Server
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server" /v DisabledByDefault /t REG_DWORD /d 1 /f
# Disable TLS 1.1 Client
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client" /v DisabledByDefault /t REG_DWORD /d 1 /f
# Enable TLS 1.2 explicitly (it may be on by default, but explicit is better)
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server" /v DisabledByDefault /t REG_DWORD /d 0 /f
# Enable TLS 1.3
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.3Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.3Server" /v DisabledByDefault /t REG_DWORD /d 0 /fA reboot is required for SCHANNEL changes to take effect. These settings apply to all TLS-dependent services on the server, not just RDP — so plan accordingly if other services like IIS are present.
Configuring Network Level Authentication
Network Level Authentication (NLA) requires the connecting user to authenticate before a full RDP session is established. Without NLA, the Windows logon screen is rendered for unauthenticated users, which wastes server resources and exposes the session to credential-stuffing attacks. With NLA enabled, Kerberos or NTLM authentication occurs at the network layer before the session desktop is created.
Enable NLA via Group Policy:
Computer Configuration > Administrative Templates > Windows Components
> Remote Desktop Services > Remote Desktop Session Host > Security
Setting: Require user authentication for remote connections by using
Network Level Authentication
Value: EnabledOr via registry:
HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
Value: UserAuthentication
Type: DWORD
Data: 1You can also set NLA using PowerShell on the local machine:
(Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(1)Replacing the Self-Signed RDP Certificate with a CA Certificate
By default, Windows generates a self-signed certificate for RDP, which causes certificate warnings on every connection and provides no chain of trust. Replacing this with a certificate from your internal Certificate Authority (CA) or a public CA eliminates warnings and enables proper certificate validation.
The Group Policy setting for this is:
Computer Configuration > Administrative Templates > Windows Components
> Remote Desktop Services > Remote Desktop Session Host > Security
Setting: Server authentication certificate template
Value: Enabled — specify the name of your certificate template
(e.g., "RemoteDesktopComputer")First, create a certificate template in the CA. Duplicate the Computer template, name it “RemoteDesktopComputer”, and ensure the following settings are configured:
Subject Name tab: Supply in the request (or Build from AD)
Extensions tab: Application Policies must include "Remote Desktop Authentication" (1.3.6.1.4.1.311.54.1.2)
Security tab: Domain Computers must have Enroll permissionAfter publishing the template on the CA and applying Group Policy, you can manually trigger certificate enrollment and configure RDP to use the new certificate:
# Request the certificate
certreq -enroll -machine "RemoteDesktopComputer"
# Get the thumbprint of the enrolled certificate
Get-ChildItem -Path Cert:LocalMachineMy | Where-Object { $_.EnhancedKeyUsageList -like "*Remote Desktop*" } | Select-Object Thumbprint, Subject
# Bind the certificate to RDP (replace THUMBPRINT with actual value, no spaces)
$thumbprint = "ABCDEF1234567890ABCDEF1234567890ABCDEF12"
$rdpSettings = Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'"
$rdpSettings.SSLCertificateSHA1Hash = $thumbprint
$rdpSettings.Put()After applying the certificate, restart the Remote Desktop Services service:
Restart-Service -Name TermService -ForceConfiguring TLS Cipher Suites for RDP
The cipher suites used by SCHANNEL determine the encryption algorithms negotiated during the TLS handshake. On Windows Server 2022, you can restrict cipher suites to only strong, modern options using Group Policy or PowerShell.
The Group Policy path for cipher suite ordering is:
Computer Configuration > Administrative Templates > Network > SSL Configuration Settings
Setting: SSL Cipher Suite Order
Value: Enabled — specify comma-separated list of cipher suitesA recommended cipher suite list for Windows Server 2022 that supports both TLS 1.2 and TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256To view currently active cipher suites via PowerShell:
Get-TlsCipherSuite | Format-Table -Property Name, Certificate, Hash, Exchange, CipherTo disable a specific weak cipher suite:
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_RC4_128_SHA"
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_RC4_128_MD5"Testing RDP TLS Configuration with nmap
After applying all changes, validate the RDP TLS configuration from an external host using nmap with the RDP enumeration script:
nmap -p 3389 --script rdp-enum-encryption 192.168.1.100Expected output when properly configured with TLS and NLA:
3389/tcp open ms-wbt-server
| rdp-enum-encryption:
| Security layer
| CredSSP (NLA): SUCCESS
| SSL: SUCCESS
| RDP Encryption level: Client Compatible
|_ RDP Protocol Version: RDP 5.x, 6.x, 7.x, 8.x, 10.xIf TLS 1.0 responses still appear after the SCHANNEL changes, verify a reboot occurred. Also check for applications that may be re-enabling older protocols via their own configuration.
Additionally, you can test from PowerShell using the .NET SslStream class to verify the TLS version being negotiated:
$tcpClient = New-Object Net.Sockets.TcpClient("192.168.1.100", 3389)
$sslStream = New-Object Net.Security.SslStream($tcpClient.GetStream())
$sslStream.AuthenticateAsClient("192.168.1.100")
Write-Host "Protocol: $($sslStream.SslProtocol)"
$tcpClient.Close()Troubleshooting with Event ID 36871 and SCHANNEL Errors
SCHANNEL errors are logged in the System event log. Event ID 36871 indicates a fatal alert was received from the remote system, typically due to a cipher suite or TLS version mismatch. To view these events:
Get-WinEvent -LogName System -FilterXPath "*[System[EventID=36871]]" | Select-Object TimeCreated, Message | Format-ListOther relevant SCHANNEL event IDs include:
36870 - A fatal error occurred while creating an SSL/TLS server credential
36872 - No suitable default server credential exists
36874 - TLS handshake failed (client closed connection)
36888 - Fatal alert generated (look at the alert description)To enable verbose SCHANNEL logging for deep troubleshooting:
reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL" /v EventLogging /t REG_DWORD /d 7 /fValue 7 enables logging of error events, warnings, and informational events. Set back to 1 (errors only) after troubleshooting is complete to avoid event log flooding.
Additional Hardening Recommendations
Beyond TLS configuration, consider these additional RDP hardening steps for Windows Server 2022. Change the default RDP port from 3389 to a non-standard port to reduce automated scanning exposure — update the registry value at HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-TcpPortNumber and update Windows Firewall accordingly. Restrict RDP access by IP using Windows Firewall or network-level ACLs. Enable account lockout policies to mitigate brute-force attempts. Consider requiring MFA for RDP connections using tools like Duo Security or Azure AD-joined device policies. Finally, ensure RDP access is audited via Advanced Audit Policy — enable “Audit Logon Events” and “Audit Account Logon Events” to capture all authentication activity on port 3389.
# Change RDP port to 3390 (example)
$rdpPort = 3390
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp" -Name PortNumber -Value $rdpPort
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound -Protocol TCP -LocalPort $rdpPort -Action Allow
Remove-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)" -ErrorAction SilentlyContinueProperly configured TLS for RDP on Windows Server 2022 significantly reduces the attack surface of one of the most exposed administrative interfaces. Combining TLS 1.2/1.3 enforcement, NLA, CA-issued certificates, and modern cipher suites provides a defense-in-depth posture that meets the requirements of most enterprise security frameworks including CIS Benchmarks and DISA STIGs.
