How to Sign an RDP Shortcut with a Code Signing Certificate

If you’ve opened an .rdp file recently and got stopped by a warning telling you the publisher can’t be identified, you’re not imagining things. Microsoft tightened how Windows handles Remote Desktop connection files, and unsigned .rdp shortcuts now trigger a caution prompt every time, with clipboard and drive redirection disabled by default until the file is signed. For IT teams distributing RDP shortcuts to staff, clients, or remote contractors, this turned a non-issue into a support ticket generator almost overnight.

The fix is signing your .rdp files with a code signing certificate. Once signed, the connection dialog shows your organization’s verified name instead of a red warning, and redirection settings work the way you configured them. This guide walks through the full process: picking the right certificate, signing the file, verifying it worked, and rolling it out across a fleet of machines without breaking anything for end users.

Why RDP Files Need to Be Signed Now

Remote Desktop connection files were never treated as executable code, so for years they got a pass from the kind of publisher checks that .exe and .msi files went through. That changed with recent Windows updates. Windows now checks .rdp files against a signature the same way it checks installers, and an unsigned file gets flagged as untrusted.

Two things happen when someone opens an unsigned .rdp shortcut:

• A warning dialog appears stating the publisher can’t be identified, and the user has to manually confirm they want to proceed
• Drive redirection and clipboard redirection are blocked by default, even if you’ve configured them in the file, until the user manually re-enables them for that session

Neither of these is fatal, but both create friction. If you’re handing out RDP shortcuts to fifty remote employees or a client base that connects to hosted desktops, that’s fifty support calls asking why copy-paste stopped working.

What You Need Before You Start

Before signing anything, make sure you have:

• Administrator access on the machine you’re using to sign files
• A code signing certificate — either self-signed, issued by an internal CA, or purchased from a public certificate authority (covered below)
• PowerShell, to generate or install the certificate and pull its thumbprint
• The Windows SDK or a Windows installation that includes rdpsign.exe (it ships with Windows by default on most modern builds; if it’s missing, it’s available through the Windows SDK)

Picking the Right Certificate for the Job

Not every certificate is built for the same use case. Which one you pick depends on who’s opening the signed files and how many machines are involved.

Self-Signed Certificate

A self-signed certificate costs nothing and takes a few minutes to generate. It works fine for testing on one machine or a small internal team where you control every endpoint. The catch: every machine that needs to trust the signed file has to have your certificate manually imported into its Trusted Root and Trusted Publisher stores. That’s manageable for five machines. It’s not manageable for five hundred, and it doesn’t scale to external clients or contractors at all, since you’d be asking someone outside your organization to trust a certificate you generated on your own laptop.

Certificate from an Internal Certificate Authority

If your organization runs Active Directory Certificate Services, this is usually the cleanest option for internal distribution. Every domain-joined machine already trusts your internal CA automatically, so there’s no manual certificate installation step on each endpoint. You issue a code signing certificate template from your CA, sign your .rdp files with it, and domain machines trust them without any extra configuration. The limitation is the same as with self-signed certs: this only covers machines joined to your domain. Anyone outside it — remote contractors, client machines, BYOD devices — won’t trust the signature.

Commercial Code Signing Certificate

For .rdp files going to machines you don’t control — client environments, contractor laptops, anything outside your domain — a commercial code signing certificate from a publicly trusted CA is the only option that works without asking the recipient to install anything first. Public CAs are already in the Trusted Root store on virtually every Windows machine by default, so a file signed with a publicly trusted cert shows the verified publisher name immediately, with no manual trust step on the recipient’s end. This is the right call if you’re a managed service provider, a SaaS company distributing RDP access to customers, or any organization where “ask the user to import a certificate first” isn’t a realistic ask.

Getting and Locating Your Certificate

Once you’ve decided which certificate type fits, get it installed in the right certificate store before trying to sign anything.

If you’re generating a self-signed certificate for testing, PowerShell’s New-SelfSignedCertificate cmdlet with the -Type CodeSigningCert parameter creates one and drops it into your local certificate store. If you’re working with an internally issued or purchased certificate, install it into Cert:\CurrentUser\My or Cert:\LocalMachine\My, depending on whether you want it available for just your user account or every user on the machine.

Once it’s installed, confirm it’s there and grab its thumbprint:

Get-ChildItem -Path Cert:\CurrentUser\My | Format-List

This lists every certificate in that store along with its thumbprint, subject, and expiration date. Copy the thumbprint for the certificate you plan to sign with — you’ll need it for the next step, and it’s easy to grab the wrong one if you have several certificates installed.

Signing the File with rdpsign.exe

With the certificate installed and the thumbprint copied, signing is one command:

rdpsign.exe /sha256 <thumbprint> C:\Path\to\your-file.rdp

Swap in the actual thumbprint and file path. If it works, you’ll get a short confirmation that the file was signed. If you open the .rdp file afterward in a plain text editor, you’ll see a signature block appended at the end — that’s the embedded CMS/PKCS#7 signature Windows checks against when the file is opened.

One thing worth knowing before you build this into any kind of deployment pipeline: the signature is tied to the exact contents of the file. Change a single setting after signing — even something as small as a redirected drive letter — and the signature breaks. The file goes back to showing as unsigned. Sign files as the last step in your process, after all settings are finalized, not before.

Verifying the Signature Worked

Don’t just assume the command ran clean. Test it the way an end user would: copy the signed file to a test machine (ideally one that doesn’t already trust your certificate, so you can see the actual behavior), and double-click it.

If the certificate is trusted on that machine, you’ll see your organization’s name in the connection dialog instead of a warning. If it’s not yet trusted, you’ll still see the warning, but the publisher name should now be readable rather than “unknown” — which confirms the signature itself is valid, even if the trust chain isn’t set up on that particular machine yet.

Getting the Signed File Trusted on Other Machines

Signing solves half the problem. The file also has to be trusted by whatever machine opens it, and how you handle that depends on which certificate type you went with.

Self-signed or internal CA certificate, non-domain machines: export the public certificate and import it manually into each machine’s Trusted Root Certification Authorities and Trusted Publishers stores.

Export-Certificate -Cert $cert -FilePath "C:\Certs\rdp-signing-public.cer"

Then on each target machine, as an administrator:

Import-Certificate -FilePath "C:\Certs\rdp-signing-public.cer" -CertStoreLocation "Cert:\LocalMachine\Root"
Import-Certificate -FilePath "C:\Certs\rdp-signing-public.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher"

Internal CA, domain-joined machines: nothing to do — trust is already in place through Active Directory.

Commercial code signing certificate: nothing to do here either. Publicly trusted CAs are already in every Windows machine’s Trusted Root store, so signed files are trusted the moment they’re opened, regardless of domain membership.

Configuring Group Policy for a Fleet Rollout

For domain environments, Group Policy lets you manage trust centrally instead of touching every machine by hand. The relevant settings live under:

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

Two policies matter here:

• Allow .rdp files from valid publishers and user’s default .rdp settings — set to Enabled
• Specify SHA1 thumbprints of certificates representing trusted .rdp publishers — set to Enabled, then add the signing certificate’s thumbprint to the list

For fleets managed through Intune rather than traditional Group Policy, the equivalent settings are available under the ADMX_TerminalServer configuration service provider, so you’re not locked out of this if you’re managing a cloud-first environment.

Common Problems and How to Fix Them

rdpsign.exe returns an error about the certificate not being usable for signing. This usually means the certificate’s signature hash algorithm doesn’t match what you’re asking rdpsign to use, or the certificate doesn’t have Code Signing listed under Enhanced Key Usage. Check both before assuming the certificate itself is bad.

The signature disappears after the file was edited. Expected behavior, not a bug. Any change to the file content invalidates the signature. Re-sign after every edit, and build that into your process if files get updated regularly.

The warning still appears even though the file is signed. Almost always a trust issue, not a signing issue. The certificate that signed the file isn’t in the Trusted Root or Trusted Publisher store on the machine opening it. Walk back through the distribution steps above for the certificate type you’re using.

Redirection is still blocked after signing. Confirm the publisher trust settings in Group Policy or local security policy are actually applied and that the correct thumbprint is listed — a mismatched or outdated thumbprint after a certificate renewal is a common cause here.

Frequently Asked Questions

How do I stop the “unknown publisher” warning when opening an RDP file? Sign the .rdp file with a code signing certificate using rdpsign.exe, and make sure the certificate is trusted on the machine opening the file.

What certificate do I need to sign an RDP shortcut? Any certificate with the Code Signing Enhanced Key Usage set works technically. Which type makes sense — self-signed, internal CA, or a publicly trusted commercial certificate — depends on whether the files are going to domain machines you control or to external users and client machines.

Can I sign an RDP file with a self-signed certificate instead of buying one? Yes, and it costs nothing. The tradeoff is that every machine opening the file has to manually trust that certificate first, which doesn’t scale past a handful of internal machines.

Why is Windows blocking clipboard and drive redirection on my RDP connection? Recent Windows updates disable redirection features by default on unsigned .rdp files as a security measure. Signing the file with a trusted certificate restores the configured redirection behavior.

How do I add a certificate thumbprint to the trusted RDP publishers list via Group Policy? Under Remote Desktop Connection Client policies, enable “Specify SHA1 thumbprints of certificates representing trusted .rdp publishers” and add the thumbprint of your signing certificate to the list.

What’s the difference between using an internal CA and a commercial code signing certificate for RDP files? An internal CA is trusted automatically by domain-joined machines only. A commercial certificate from a public CA is trusted by any Windows machine by default, which matters if your files go to non-domain devices or external users.

How do I find a certificate’s thumbprint in PowerShell for RDP signing? Run Get-ChildItem -Path Cert:\CurrentUser\My | Format-List and copy the thumbprint of the certificate you plan to use.

Does rdpsign.exe require SHA-256, or will SHA-1 certs still work? rdpsign.exe expects a SHA-256 signature hash. Older certificates using SHA-1 as the signature algorithm can fail to sign, even if the thumbprint itself is entered correctly.

How do I make a signed RDP file show as trusted on my colleagues’ machines too? Export the public certificate and import it into the Trusted Root and Trusted Publisher stores on each machine, unless you’re using an internal CA on domain-joined machines or a publicly trusted commercial certificate, both of which skip this manual step entirely.

Bottom Line

Signing .rdp files isn’t optional anymore if you’re distributing Remote Desktop shortcuts to anyone outside a tightly controlled test environment. Self-signed and internal CA certificates work for internal, domain-bound deployments. The moment your files reach machines you don’t control, a publicly trusted code signing certificate is the only option that avoids asking every recipient to manually trust a certificate before they can connect.