RDP file signing

Signing an RDP file

Use the sign command with the .rdp path — no special flags required, the file type is auto-detected:

SignotaurTool.exe sign -a <APIKey> -s <SignServer> -t <Thumbprint> --fd SHA256 connection.rdp

Timestamping (--tr, --td) and the other common sign options work as usual. See the sign command reference for full details.

Certificate Requirements

The signing cert must be registered in Signotaur as a code-signing certificate, and it must be an RSA certificate. ECDSA certificates are not supported for RDP signing:

• Signotaur's RDP signer routes through the same CMS infrastructure as NuGet/VSIX signing, which is RSA-only (RemoteSigningKey extends RSA with PKCS#1 padding).
• Microsoft's own rdpsign.exe and mstsc.exe have no documented or community-validated ECDSA support. Every working recipe — including the post-KB5083769 trust-policy approach described below — uses RSA + SHA-256.

For background on supported certificate types, key sizes, and the CA/Browser Forum RSA 3072-bit minimum for publicly-trusted code signing certificates, see Code Signing Certificates.

How Windows Remote Desktop Connection handles signed .rdp files

After Windows installs the April 2026 cumulative update (KB5083769, part of CVE-2026-26151), Remote Desktop Connection has three distinct behaviours for a signed .rdp file based on client-side trust state:

The goal for production deployment is to get recipient machines to the no-dialog state. This needs two layers of configuration on the recipient side, described below.

Recipient configuration

Layer 1 — trust the signing cert's chain

If the signing cert is a commercial code-signing certificate that chains to a Microsoft-preinstalled root (e.g. DigiCert, Sectigo, GlobalSign), no recipient action is needed for this layer — the root is already trusted on every Windows machine.

If the signing cert is self-signed or chains to a private/internal CA, each recipient machine needs the cert (or the CA's cert, for chained certs) imported into the Root store:

Import-Certificate -FilePath <cert-or-ca>.cer -CertStoreLocation Cert:\CurrentUser\Root

Use Cert:\LocalMachine\Root instead for machine-wide trust (requires admin). This moves the dialog from red to yellow.

Layer 2 — add the publisher's thumbprint to the trust policy

Adding the signing cert's SHA-1 thumbprint to the Remote Desktop Connection trust policy elevates the dialog from yellow to no-dialog.

Per-user (no admin needed):

$p = 'HKCU:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $p -Force | Out-Null
Set-ItemProperty -Path $p -Name AllowSignedFiles -Value 1 -Type DWord
Set-ItemProperty -Path $p -Name TrustedCertThumbprints -Value '<SIGNING_THUMBPRINT>' -Type String

Machine-wide (admin required — suitable for GPO / Intune deployment):

$p = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $p -Force | Out-Null
Set-ItemProperty -Path $p -Name AllowSignedFiles -Value 1 -Type DWord
Set-ItemProperty -Path $p -Name TrustedCertThumbprints -Value '<SIGNING_THUMBPRINT>' -Type String

The thumbprint must be uppercase, no spaces. Multiple publishers can be trusted by semicolon-separating their thumbprints in the TrustedCertThumbprints value, e.g. 'AABB...CCDD;1122...3344'.

Fleet deployment via Group Policy

The same two policy values are exposed in the Group Policy Editor at:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Connection Client

• Allow .rdp files from valid publishers and user's default .rdp settings → Enabled
• Specify SHA1 thumbprints of certificates representing trusted .rdp publishers → Enabled, and add the signing cert's thumbprint to the list.

For domain-joined fleets these settings can be deployed via a GPO; for MDM-managed devices use the equivalent Intune / CSP settings under ADMX_TerminalServer.

Separate timestamping

Timestamping is normally applied inline during signing via the --tr / --td flags on the sign command. For CI pipelines where signing and timestamping are staged separately — for example, signing offline and timestamping later after releasing the file — the timestamp subcommand supports .rdp files the same way it does for .nupkg, .vsix, and CMS files:

SignotaurTool.exe sign -a <APIKey> -s <SignServer> -t <Thumbprint> --fd SHA256 connection.rdp
SignotaurTool.exe timestamp --tr http://timestamp.digicert.com --td SHA256 connection.rdp

The timestamp step strips the Microsoft 12-byte header, adds an RFC 3161 unsigned attribute to the embedded CMS SignedData, re-wraps the header, and rewrites the file atomically. Running timestamp against an unsigned .rdp skips it with a "not signed" message rather than failing.

See the timestamp command reference for full syntax and fallback-server options.

Post-sign guidance output

After Signotaur successfully signs an RDP file, it prints a guidance block containing the signing cert's thumbprint already substituted into the PowerShell recipe — recipients can copy it verbatim. When running interactively on Windows, the tool additionally offers to apply the policy to the current user's registry so you can test the signed file locally without further setup.

To suppress the guidance (for CI / automation where it's just log noise):

SignotaurTool.exe sign ... --nmg connection.rdp

Equivalent long form: --no-mstsc-guidance.

Troubleshooting

References

• Microsoft Learn: Understanding security warnings when opening RDP files
• Microsoft Learn: ADMX_TerminalServer Policy CSP
• Sign command reference
• Verify command reference