RDP Proxy Certificate Options

Remote Desktop Protocol uses SSL to secure connections. To enable this process, all Windows machines present an RDP Server SSL certificate when a client initiates the process to establish a connection. In a default configuration, this is a self-signed certificate generated by Windows when the RDP service is first enabled.

RDP Proxy Context

The global RDP server certificate configured on Admin > Proxying > RDP uses in-database PFX storage. You can specify certificate overrides for individual distributed engine sites and engines as secrets of type PFX—see Per-Site and per-Engine Certificates below.

The Secret Server RDP Proxy also has a default, shared, self-signed SSL certificate, with the facility to create a new self-signed certificate, or to provide your own. In the case of RDP Proxy, Remote Certificates refers to the target machine specified at the time of secret launch.

Configuration

Secret Server provides two distinct configuration areas for SSL certificates in relation to the RDP proxy. This page describes what their configuration means, along with the options available to best utilize or mitigate user experience objections.

Accessing the RDP Server Certificate

The global RDP server certificate configured on Admin > Proxying > RDP uses in-database PFX storage. Certificate overrides for individual distributed engine sites and engines can be specified as secrets of type PFX—see "Per-site and per-engine certificates" below.

  1. Access Secret Server.

  2. Access Settings > Proxying > RDP and locate RDP Server Certificate on the page, next to it is the downloadable .pfx file. This is always in use when utilising the RDP Proxy.

This is the SSL certificate presented by the RDP Proxy to the user’s RDP Client (MSTSC.exe or Connection Manager) when a user launches from a secret.

Validating Remote Certificates

  1. Access Settings > Proxying > RDP.

  2. On the RDP Proxy tab find Validate Remote Certificates. This option determines whether the RDP Proxy should validate the launch target’s RDP certificate.

    • Yes—the target’s RDP certificate will under go the SSL validation process – failure to validate will cause the connection to be dropped.

    • No—the target’s RDP certificate will not be subject to validation checks. Any failure to connect will not be due to target RDP certificate validation.

Disabling Remote Certificate Validation for RDP Proxy

Delinea recommends that you operate in an environment where RDP server certificates are created by a controlled CA and are trusted by machines in the domain. If that is not possible, you can disable remote certificate validation to allow connection to machines that do not serve trusted certificates.

To change the certificate settings, in Windows:

  1. Go to Console Root\Certificates(Local Computer)\Remote Desktop\Certificates. The Console appears.

  2. Note that these remote server Remote Desktop certificates are self-signed by default.

    Secret Server RDP proxy cannot validate these unless one of two conditions apply:

    • Each target server certificate is imported in to all the servers hosting RDP proxy.

    • Trusted RDP certificates are deployed.

      Microsoft describes a process for the second condition in Using certificates in Remote Desktop Services.

Creating Self-Signed Certificates with Multiple Aliases

To create a self-signed certificate that can be used with multiple domain names and IP addresses, use the following PowerShell command. This example demonstrates how to specify multiple aliases for the certificate:

Copy 
New-SelfSignedCertificate `
  -Subject "DelineaSecretServer" `
  -DnsName `
    "phobos",
    "phobos.hkdr.co.uk",
    "mars1",
    "mars1.hkdr.co.uk",
    "deimos1",
    "deimos1.hkdr.co.uk",
    "10.12.60.X",
    "10.12.60.X",
    "10.12.60.X" `
  -CertStoreLocation "cert:\LocalMachine\My" `
  -HashAlgorithm SHA256 `
  -KeyLength 4096 `
  -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
  -NotAfter (Get-Date).AddYears(10)
The names and IP addresses in the command are examples. Replace them with your own values to suit your environment.

Parameters Explained:

  • subject: Specifies the subject name of the certificate.

  • DnsName: Lists the domain names and IP addresses the certificate will be valid for. Replace these with your own values.

  • CertStoreLocation: Defines where the certificate will be stored.

  • HashAlgorithm: Sets the hash algorithm to be used.

  • KeyLength: Determines the length of the cryptographic key.

  • Provider: Specifies the cryptographic provider.

  • NotAfter: Sets the expiration date of the certificate.

Per-Site and per-Engine Certificates

A distributed engine site or an individual engine can override the global RDP server certificate with a secret of type PFX. The engine uses this certificate for both the direct RDP proxy listener and the gateway listener when the override applies.

Resolution order, highest precedence first:

  1. Engine override, configured in Default Engine Settings on the Site Detail page.

  2. Site override, configured in the site edit modal on Admin > Distributed Engine > Sites.

  3. Global certificate, configured on Admin > Proxying > RDP > RDP server certificate.

Assigning a Certificate to a Site

  1. Create or identify a secret based on the PFX template containing the certificate and password.

  2. Navigate to Admin > Distributed Engine > Sites.

  3. Select the site to configure and click Edit.

  4. In the RDP Proxy section, click Select next to RDP Proxy Certificate and choose the PFX secret.

  5. Click Save.

Assigning a Certificate to a Distributed Engine

  1. On the Site Detail page, click Default Engine Settings. A popup appears.

  2. Locate the RDP Proxy Certificate field and select a PFX secret.

  3. Click Save.

Clearing an Override

Click Clear next to the RDP Proxy Certificate field at any level to revert to the next level up.

Certificate Rotation

Certificate changes take effect without iisreset or an engine service restart. Secret Server's local site picks up the change immediately on save. Distributed engines pick up the change within approximately 30 seconds.

Permissions

The user assigning a secret to a site or engine must have View permission on that secret. Attempts to reference a secret the assigning user cannot read are rejected with a permission error.

Certificate Requirements for RD Gateway

RD gateway enforces stricter certificate trust rules than direct RDP proxy. The following requirements apply to any certificate selected for gateway use, whether global, per-site, or per-engine.

Subject Alternative Name

The certificate's subject alternative name must include the exact hostname that clients use to reach the gateway. mstsc.exe rejects certificates that carry only a common name without a matching SAN.

Enhanced Key Usage

The certificate must include server authentication (1.3.6.1.5.5.7.3.1) enhanced key usage. Certificates without this EKU are rejected at the TLS handshake.

Key Type

The gateway certificate must use an RSA key pair. Gateway connections fail if the selected certificate uses a non-RSA key, such as ECDSA.

Client-Side Trust

Client machines must trust the full chain of the gateway certificate. Unlike target-host validation, gateway certificate trust cannot be relaxed in configuration—a client that does not trust the chain cannot connect.

For certificates issued by an internal Certificate Authority (CA), ensure the issuing CA's root and any intermediate certificates are installed in the trusted root CAs and Intermediate CA's stores on each client machine.

Self-Signed Certificates

Self-signed certificates are supported for lab use. Each client machine that will connect must have the self-signed certificate installed in trusted root CAs before mstsc will accept it.

Client TLS Considerations

Windows Server 2025 (24H2) and Windows 11 clients with current updates, enforce tighter TLS defaults than earlier Windows releases and may reject chains or TLS versions that older clients tolerated. Verify the gateway certificate chain is complete, intermediate certificates are published, and TLS versions are mutually supported before rolling out to clients running these newer Windows releases.