RDP and RD Gateway: SSL certificate setup

Q: Can I use a wildcard certificate for RD Gateway?

Yes, a wildcard certificate (e.g. *.your-domain.com ) works well for RD Gateway, RD Web Access and internal RDP connections, as long as all hostnames are under the same domain. It simplifies the setup because one certificate covers everything. However, consider the security implication: if the wildcard key is compromised, all services under the domain are affected.

Remote Desktop Gateway uses HTTPS to tunnel RDP traffic securely over the internet. This guide covers certificate requirements, automated setup with simple-acme, GPO distribution to RDP servers and troubleshooting.

Architecture

A typical Remote Desktop setup with a gateway has multiple components, each requiring certificates:

Internet client

MSTSC / Remote Desktop

RD Gateway

HTTPS (port 443)

Public certificate

RD Web Access

IIS (port 443)

Public certificate

RDP servers

Internal network

Internal/public cert

RD Gateway and RD Web Access typically run on the same server.

Certificate requirements

Component	Certificate type	Hostname	Note
RD Gateway	Public (DV/OV)	rdp.your-domain.com	Internet-facing, public CA required
RD Web Access	Public (DV/OV)	rdp.your-domain.com	Same hostname as gateway (IIS binding)
RDP servers	Internal / public	server01.internal.com	NLA authentication only

Setup with simple-acme

Simple-acme automates the entire certificate lifecycle: issuance, installation in Windows Certificate Store, IIS binding and binding to all RDP services. With the built-in ImportRDSFull.ps1 script, RD Gateway, RD Connection Broker, RD Web Access and the RDP listener are handled automatically on every renewal.

Simple-acme command

simple-acme.exe ^
  --baseuri https://fairssl.dk/acme/ ^
  --source manual ^
  --host rdp.your-domain.com ^
  --validationmode dns-01 ^
  --validation cloudflare ^
  --cloudflareapitoken YOUR_CF_TOKEN ^
  --csr ec ^
  --store certificatestore ^
  --installation iis,script ^
  --siteid 1 ^
  --script "Scripts\ImportRDSFull.ps1" ^
  --scriptparameters "{CertThumbprint}" ^
  --accepttos

What happens automatically?

When simple-acme runs (manually or via Task Scheduler), it performs these steps:

1 Issues or renews the certificate via ACME with DNS-01 validation
2 Imports the certificate into Windows Certificate Store (Cert:\LocalMachine\My)
3 Updates the IIS HTTPS binding (--installation iis)
4 Runs ImportRDSFull.ps1 which binds the certificate to RD Gateway, RD Connection Broker, RD Web Access and the RDP listener, and restarts the relevant services

Important settings in settings.json

In simple-acme's settings.json (or settings_default.json), set:

Store.CertificateStore.PrivateKeyExportable to true (required for RDP services)
ScheduledTask.RenewalMinimumValidDays to 15 (renew at least 15 days before expiry)

DNS validation with FairSSL AutoDNS

If you do not have API access to your DNS provider, you can use FairSSL AutoDNS instead of Cloudflare. Set up a CNAME record once, and FairSSL handles all DNS validation automatically:

# DNS: one-time CNAME setup
_dnsauth.your-domain.com  CNAME  your-unique-id.autodns.fairssl.dk.

See the simple-acme guide for full documentation of script parameters and Task Scheduler configuration.

GPO distribution (Active Directory)

This section is only relevant if your RDP servers are domain-joined Windows machines in an Active Directory environment. With Group Policy you can configure the RDP listener and NLA requirements centrally:

1 Open Group Policy Management Console and create a new GPO for RDP servers.
2 Navigate to Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
3 Enable Server Authentication Certificate Template and specify the certificate template from your internal CA, or use Require use of specific security layer for remote (RDP) connections set to SSL.
4 Under Require user authentication for remote connections by using NLA: set to Enabled to require NLA.

An internal CA certificate for RDP servers behind the gateway is a good solution. Distribute the root certificate via GPO to the clients' Trusted Root Certification Authorities store. This way all domain clients automatically trust the RDP servers' certificates.

Hosts file trick: same FQDN for gateway and internal RDP

A common scenario: RD Gateway and the RDP server use the same public FQDN (e.g. rdp.your-domain.com). The client connects to the gateway via public DNS, and the gateway must forward to the internal RDP server. But the gateway cannot resolve rdp.your-domain.com to the internal server, because public DNS points to the gateway itself.

The solution is a hosts file entry on the gateway server:

# C:\Windows\System32\drivers\etc\hosts on the RD Gateway server
10.0.1.50    rdp.your-domain.com

Now the gateway resolves rdp.your-domain.com to the internal IP (10.0.1.50) and forwards RDP traffic correctly. The client only sees rdp.your-domain.com and does not need to know the internal IP.

This approach requires the RDP server to accept connections on the rdp.your-domain.com hostname. If the RDP server uses NLA, its certificate must match rdp.your-domain.com or include it as a SAN. With a wildcard certificate (*.your-domain.com) on both servers this is automatically satisfied.

Troubleshooting

"The remote computer could not be authenticated"

The client does not trust the certificate. Check: (1) Is the certificate chain complete (intermediate + leaf)? (2) Does the hostname in the certificate match the hostname the client is connecting to? (3) Has the certificate expired? Use the SSL Scanner to verify.

RD Gateway: "Your computer can't connect to the remote computer"

Typically a certificate problem on the gateway side. Check that the certificate is bound in RD Gateway Manager (not just IIS). Run Get-Item "RDS:\GatewayServer\SSLCertificate\Thumbprint" in PowerShell to verify. Also ensure the TSGateway service has been restarted after the certificate change.

NLA fails behind gateway

NLA authentication happens between client and RDP server (not the gateway). The client must trust the RDP server's certificate. In a domain environment: distribute the certificate via GPO. Without a domain: import the root certificate manually into the client's Trusted Root store.

Certificate renewed, but gateway still uses the old one

RD Gateway caches the certificate binding. Restart the TSGateway service: Restart-Service TSGateway -Force. Check that the post-renewal script runs correctly by reviewing the log files in simple-acme's log folder.

Frequently asked questions about RDP and SSL

Find answers to the most common questions about SSL certificates and FairSSL.

Can I use a wildcard certificate for RD Gateway?

Yes, a wildcard certificate (e.g. *.your-domain.com) works well for RD Gateway, RD Web Access and internal RDP connections, as long as all hostnames are under the same domain. It simplifies the setup because one certificate covers everything. However, consider the security implication: if the wildcard key is compromised, all services under the domain are affected.

What is the difference between RD Gateway and RD Web Access?

RD Gateway is an HTTPS proxy that tunnels RDP traffic (port 443). RD Web Access is an IIS web application that displays RemoteApp icons and full-screen desktops in the browser. Both require SSL certificates and typically run on the same server. RD Gateway uses its own certificate store via RD Gateway Manager, while RD Web Access uses IIS HTTPS binding.

Do the RDP servers behind the gateway need public certificates?

Not necessarily. RDP sessions behind the gateway can use internal or self-signed certificates, since the client already has an encrypted connection via the gateway. However, for NLA (Network Level Authentication) the client must trust the RDP server's certificate. In an Active Directory environment you can distribute an internal CA certificate via GPO.

Can I automate certificate renewal with simple-acme?

Yes. Use simple-acme with DNS validation and a post-renewal script that binds the new certificate to RD Gateway and IIS. See the simple-acme guide for details on script parameters.

NLA fails with "The authentication was not successful"

NLA errors are typically caused by the client not trusting the RDP server's certificate. Check: (1) Is the certificate chain complete (intermediate + leaf)? (2) Does the certificate hostname match the name the client is using? (3) Has the certificate expired? (4) In domain environments: is the certificate distributed via GPO to the Personal store on the RDP server?

What is the difference between DV and OV for RDP?

For RD Gateway, which is exposed to the internet, we recommend OV (Organisation Validation). OV displays the company name in the certificate, giving users confidence that they are connecting to the correct organisation. DV works technically but provides no organisation identification. For internal RDP servers behind the gateway, the certificate type is less important.