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

The other common sign options work as usual. See the sign command reference for full details. RFC 3161 timestamping (--tr, --td) is supported but has an important caveat for .rdp files specifically — see Timestamping and certificate expiry below.

Certificate Requirements

The signing cert must be registered in Signotaur as a code-signing certificate. RDP signing currently requires an RSA code-signing certificate.

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.

Timestamping and certificate expiry

When you pass --tr <url> while signing a .rdp file, Signotaur embeds a standards-compliant RFC 3161 timestamp token into the CMS signature as an unsigned attribute. You can confirm this by base64-decoding the signature:s: value, stripping the 12-byte Microsoft header, and inspecting the resulting CMS — the signature-time-stamp attribute (OID 1.2.840.113549.1.9.16.2.14) will be present.

The timestamp is still worth applying:

• The CMS structure is standards-compliant — general-purpose tools (OpenSSL, audit scripts, third-party verifiers including Signotaur's own verify command) can read the signing time.
• It provides a tamper-evident audit record of when each .rdp file was signed.
• If Microsoft ever updates mstsc to honour RFC 3161 timestamps for .rdp files (plausible given the April 2026 push toward signed .rdp files), files signed today will already be future-proof.

Practical implication: plan around your signing certificate's lifetime — a 2–3 year code-signing certificate is typical — and re-sign distributed .rdp files when the certificate is renewed. Signotaur makes the renewal nearly transparent: use --label <name> (e.g. --label production) instead of --thumbprint, and your scripts will automatically pick up the renewed certificate once an admin uploads it under the same label. Re-signing itself is just running the same sign command again, so it can be wired into a CI/CD pipeline or a scheduled task with no special handling.

Separate timestamping

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