VSoft Technologies Blogs

Signing .rdp files with Signotaur (and surviving the April Windows update)

Fri, 24 Apr 2026 02:27:48 GMT

In this article:

What changed for signed .rdp files in the April 2026 Windows update
Why previously-working signatures now show an orange warning dialog
The registry policy recipient machines need for no dialog at all
How Signotaur signs .rdp files without distributing the certificate
Deploying the policy via Group Policy or PowerShell

If you push Remote Desktop shortcuts out to users, you probably already know about the April 2026 Windows cumulative update (KB5083769 on Windows 11, KB5082200 on Windows 10). If you don't, you might have found out the hard way — via a Monday-morning deluge of "is this a virus?" tickets from users who suddenly have a big orange warning on the RDP file that worked fine last week.

Signotaur 1.2.0.107 ships with .rdp file signing support. Here's what changed in Windows, why it matters, and what the new signing command actually does.

What Microsoft changed

The April cumulative addresses CVE-2026-26151. Two user-visible things came with it:

The Remote Desktop Connection warning dialog was redesigned. It now lists every resource the connection can redirect (drives, printers, clipboard, USB, etc.) with individual checkboxes, and every box is off by default. Users have to opt in to each one on every connection, every time.
The trust criteria for signed .rdp files tightened. Pre-April, a file signed by an untrusted cert got a yellow "Verify the publisher" banner. Post-April, the same file gets an orange "Caution: Unknown remote connection" banner — visually indistinguishable from an unsigned file.

Here's what the new per-launch dialog looks like. For an unsigned file:

And for a file signed by a publisher Windows can verify:

Separately, the first time any user opens an .rdp file after installing the update, Windows shows a one-time educational dialog explaining what .rdp files are and why they can be dangerous:

Once dismissed, it doesn't reappear for that account.

Discussion and lament: r/sysadmin: FYI: Microsoft RDP changes with April cumulative.

This is a genuinely good security change — the old dialog was vague and under-informed users about what was being shared with the remote host. It is also a rather annoying deployment change, because plenty of teams had rdpsign.exe-signed files quietly working for years, and now they don't.

Why people got caught out

The usual story goes like this: a team signed their .rdp file years ago with a self-signed or internal-CA certificate, shipped it to users, and it displayed a friendly yellow "Verify the publisher: Acme Corp" dialog that everyone clicked through. After April's update, the same file suddenly shows an orange "Unknown remote connection" dialog and support gets flooded. One representative example from the Reddit threads: a sysadmin describing exactly this.

The signatures on those files are still cryptographically valid. Windows is just stricter now about what counts as a "verified publisher" for RDP.

The actual recipe (no dialog at all)

Cutting through the noise, here's what recipient machines need for a signed .rdp file to open with no warning dialog at all:

The signing certificate's chain must terminate in a root the client machine trusts. Commercial code-signing certs (DigiCert, Sectigo, etc.) chain to roots Windows already trusts. For an internal CA or self-signed cert, the root has to be imported into Cert:\*\Root on each client.
A Remote Desktop trust policy must be in place that whitelists your signing certificate's SHA-1 thumbprint. This lives at either HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (machine-wide, requires admin) or HKCU\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (per-user, no admin required), and needs two values:
- AllowSignedFiles — REG_DWORD, set to 1
- TrustedCertThumbprints — REG_SZ, the SHA-1 thumbprint of your signing cert, uppercase, no spaces (semicolon-separated if you have more than one)

A word of warning about one trap we hit: TrustedCertThumbprints is a whitelist on top of normal chain validation, not a replacement for it. Dropping a self-signed cert's thumbprint into the list without also importing the cert into a trusted root store does nothing. If you've tried this and wondered why it didn't work, that's why.

What Signotaur does when you sign a .rdp file

Unlike rdpsign.exe, Signotaur signs .rdp files against a remote server — the private key stays on the server (or an HSM it's connected to), so no admin workstation or automation host needs a local copy of the signing certificate. This is the main reason to use Signotaur for .rdp signing rather than running rdpsign.exe directly.

The mechanics otherwise match what you'd expect. The client reads the .rdp file, canonicalises the contents, sends only the digest to the server for signing, and writes the signed file back in place. The output is byte-equivalent to rdpsign.exe's — same canonical form, same 12-byte Microsoft wrapper, same detached CMS structure — so recipients see the same Windows Remote Desktop Connection dialog regardless of which tool produced the signature.

RFC 3161 timestamping is supported, and the timestamp is embedded into the CMS in the standard way. But there's a caveat that's easy to miss: mstsc.exe doesn't actually consult the timestamp when validating a .rdp signature — it only checks whether the signing certificate is currently valid at the moment the file is opened. The strongest indirect evidence for this is that Microsoft's own rdpsign.exe has no timestamping support at all — no /tr flag, no timestamp in its output.

The timestamp is still worth having: it's standards-compliant CMS so general-purpose tools can read the signing time, it provides a tamper-evident audit trail, and it future-proofs against any future change in mstsc's behaviour. In practice though, plan to re-sign distributed .rdp files when your signing certificate is renewed, the same way you would for an unsigned-but-distributed file.

Because the registry recipe above is easy to get wrong, Signotaur also prints the recipe for you after signing, pre-filled with the thumbprint of the certificate that just signed the file. It tells you whether the cert is self-signed (in which case you'll also need to deploy the cert itself to recipient trusted-root stores) or chained (in which case you may not).

If you're running sign interactively on Windows, it also offers to apply the policy to HKCU for the current user on the spot — no admin rights needed, no registry editor, no PowerShell snippet to copy-paste. This is mostly useful for confirming the signing works locally before you deploy the policy via GPO. In unattended runs, the prompt is automatically skipped, and you can pass --no-mstsc-guidance (--nmg) to suppress the whole lot if the log gets noisy.

An example

The sign command detects .rdp files automatically based on extension, so there's nothing special to type:

	
			SignotaurTool.exe sign -a  -s  -t  --tr http://timestamp.digicert.com --td SHA256 connect-to-prod.rdp

After a successful sign you'll see something along the lines of:

RDP signing guidance (Windows Remote Desktop Connection compatibility, post-KB5083769):

By default recipients will see a "Verify the publisher" or "Unknown publisher"
warning dialog when opening this signed file in Windows Remote Desktop Connection.
To eliminate the warning, each recipient machine needs:

1. The signing certificate's chain trusted on the machine.
   For commercial certificates chaining to a Windows-preinstalled root, no action
   is required; internal-CA certificates require the CA to be imported into each
   recipient's Trusted Root store.

2. The signing certificate's thumbprint added to the Remote Desktop trust-publisher
   policy:

   Value: AllowSignedFiles (REG_DWORD) = 1
   Value: TrustedCertThumbprints (REG_SZ) = 

Apply AllowSignedFiles + TrustedCertThumbprints to your current user registry now?
Useful for testing this signed .rdp locally. [y/N]:

Answer y and it writes the values to your HKCU — open the file in Remote Desktop Connection, confirm there's no dialog, and you know the signing bit is working before you take the policy near a GPO.

Deploying the policy to the fleet

For anything beyond a couple of machines, Group Policy is the right tool — it's also how you set these same values without touching the registry by hand. In the Group Policy Management Editor:

Computer (or User) 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, with your thumbprints in the list (uppercase, semicolon-separated if multiple)

Intune has equivalent settings under the Administrative Templates profile. If you're deploying to a smaller set of machines, or scripting it, a PowerShell snippet that does the per-user version (no admin needed) looks like this:

	
			$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 'YOUR_THUMBPRINT_UPPERCASE' -Type String

Swap HKCU for HKLM for the machine-wide version (and run elevated). The thumbprint must be uppercase with no spaces; use a semicolon to join multiple thumbprints if you have more than one signing cert in rotation.

What you still can't do

A few things worth knowing up front so you don't hunt for them:

The per-redirection checkboxes in the new dialog are not controlled by AllowSignedFiles. Even with a properly trusted and whitelisted signature, users still see the redirection dialog on first use. There's a separate set of policies for which redirections are allowed on the server side; the client-side checkboxes are a user-consent UI rather than a trust decision.
There's a temporary "revert to pre-April dialog" switch at HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client\RedirectionWarningDialogVersion = 1. Don't rely on it — Microsoft has been explicit that it will be removed in a future update.
Windows has no built-in .rdp signature verifier. rdpsign.exe /v is "verbose", not "verify"; in practice the only verifier is Remote Desktop Connection opening the file. Signotaur's verify command will validate the signature and cert chain offline if you want a CI-friendly check.

If you'd rather not think about any of this

The short version: get a code-signing certificate from a public CA that chains to a Windows-preinstalled root, register it with your Signotaur server, sign your .rdp files as part of your distribution workflow, and push the AllowSignedFiles + TrustedCertThumbprints policy out via GPO. After that, signed .rdp files open with no dialog, and the next time Microsoft tightens the rules you've already done the trust-deployment work.

For command-line details and the full signing command reference see the Signotaur documentation. If you run into something specific — especially if you have an internal CA or a less-common PKCS#11 token in play — our support team is happy to help.

FinalBuilder 8.5 and Automise 5.5 Release

Wed, 09 Apr 2025 01:50:56 GMT

It's no secret that we are always working on the next version of FinalBuilder and Automise - that's the nature of software development. That said, the next major versions are taking much longer than we would like - the reason for this is dealing with serious technical debt (active scripting).

With this extended development cycle, there are changes that we finished some time ago that we decided just could not wait for the next major version. We backported those changes to the FinalBuilder 8.x and Automise 5.x - but since some of these changes break project compatibility (with the x.0 releases) we are releasing FinalBuilder 8.5 and Automise 5.5

Encryption Algorithm

FinalBuilder & Automise have always used the Blowfish algorithm (with a 160 bit key) for encrypting passwords, apikeys etc.

FinalBuilder 8.5/Automise 5.5 adds the AES 256 Algorithm (with a 256 bit key) as an option.

There is a new IDE option to specify the default project encryption for new projects - this defaults to AES256. Note this only affects New projects. To change the algorithm used for existing projects, open the project info window from the Project Menu, change the setting and click ok and then save the project.

Note that these options will be removed in FinalBuilder 9/Automise 6, when AES 256 will become the default (and projects still using Blowfish will be upgraded automatically).

It's should be noted that Blowfish is still considered reasonably secure, this change is to enabled the continued use of FinalBuilder in organisations must comply with NIST (US) or ASD (Australia) requirements.

Password Variables

In FinalBuilder & Automise we have always attempted to mask passwords from the logs, but occasionally that can slip through.

Any passwords stored in variables were visible in plain text in project project files. For this reason, we have added a new Password variable type. These variables will be encrypted in project files. The backing type is string.

Password UI

All password fields on all now utilise a new password edit control that allows peeking at the value (like the windows 11 password box).

Windows Credential Manager Actions

The Windows Credential Manager actions enable you to read/write/delete credentials stored in the credential manager.

Project file compatibility Warning

FinalBuilder 8.5 project files are NOT downward compatible with FinalBuilder 8.0 - or put another way, FinalBuilder 8.0 cannot load FinalBuilder 8.5 projects. The same applies to Automise 5.5 projects. This is due to some of the changes outlined above.

FinalBuilder 8.0.0.3378 and Automise 5.0.0.1593 breaking changes.

Tue, 16 Jul 2024 05:30:16 GMT

Throughout the lifespan of FinalBuilder and Automise, we have worked very hard to avoid breaking changes - however sometimes they are unavoidable.

Today's updates to FinalBuilder 8 and Automise 5 have a breaking change in the SSH Batch Execute action. Previously, this action would manage it's own connect/disconnect - the breaking change is this action now requires separate SSH Connect/Disconnect actions.

The reason for this is complicated, but it was brought about by us changing the client library we use for the SSH actions. The previous client library had too many issues that we were unable to work around. The most annoying example - the actions would not work correctly/reliably with openssh running on windows servers. We did try to fix this issue, but in the end the only viable option was to replace the library (something we were planning to do in the future anyway). The new library (Rebex) is much more stable and performant. We plan to re-implement the SFTP actions (which have issues with some servers) with this library in a future update.

We have been using a build with these changes in production for some time now to dogfood these changes.

To use the SSH Batch Execute action, add an SSH Connect action before it and an SSH Disconnect after, set the connection name on the SSH Batch Execute and SSH Disconnect to the name of the new SSH Connect action's connection name and you should be all set.

If you experience any issues with the SSH actions in these new updates let us know (with as much info as you can about the server and action settings).

Managing Delphi Version Info with FinalBuilder

Wed, 26 Jun 2019 15:49:26 GMT

In this post, we'll take a look at the various options for managing and updating Version Info in Delphi projects using FinalBuilder.

Windows Version Info Primer

Windows Version Info (ie the version info shown in explorer) is stored in a VERSIONINFO resource inside the executable (exe or dll). These resources are created by defining a .rc file, and compiling with either the windows resource compiler (rc.exe) or Delphi's provided resource compiler (brcc32 or cgrc depending on the delphi version). This results in a .res file, which can be linked into exe at compile time by referencing it in the source code, e.g :

{$R 'myresource.res'}

I highly recommend familiarising yourself with the VERSIONINFO resource type and it's parts.

Delphi IDE Support for Version Info

The Delphi IDE creates a [YourProjectName].res file next to the dpr or dpk when you create a new project. This is where the IDE will place the VERSIONINFO resource when you enable the option to "Include version information in project". When you compile the project in the IDE, if needed the IDE will regenerate this res file with updated version info before it is linked into the executable. For exe's, this resource file also includes the MAINICON resource (the icon shown in explorer).

You do not have to use this feature, you can leave the option turned off and manage the version info yourself, by creating your own resource script (.rc) with a VERSIONINFO structure, and compiling it and referencing the resulting .res file in your source code. You can even just reference the .rc file

{$R 'myresource.res' 'myresource.rc'}

and the IDE will compile the rc file and link in the resulting res file. The caveat to this technique is that the command line compiler (dcc32, dcc64 etc) does not support this.

If your binary doesn't have version info, or has incorrect version info, it's typically because :

1) The version info resource wasn't referenced in the source and wasn't linked in
2) There are duplicate VERSIONINFO resources linked, windows will pick the first one it finds.
3) You set the version info on the wrong IDE configuration (more on this below).

The Delphi IDE, along with the dproj file (which is an msbuild project file), uses a convoluted configuration inheritance mechanism to set project properties, including version info. Many a developer has been caught out by this scheme, setting the version info at the wrong node in the heirachy, resulting in no version info in their executables. There have also been issues with dproj files that have been upgraded through multiple versions of delphi over the years.

Using FinalBuilder

In the development environment, the version info usually doesn't matter too much, but for formal releases it's critical, so it's best to leave setting/updating your version info to your automated build tool or your continuous integration server. In FinalBuilder we have invested a lot of time and energy to making version info work correctly with all the different versions of delphi, dealing with the vagaries and subtle differences with each version (and there are many!).

On the Delphi action in FinalBuilder, the Version Info tab presents the version info in a similar way to old versions of delphi IDE did (a much nice ui that the current version imho). This ui allows you control all the various version info properties (and there are a lot!). Note that these will only take effect if you have the "Regenerate resource" option checked on the Project tab (ie, regenerate yourproject.res).

Note that the Major, Minor, Release and Build fields are number spin edits, and cannot take FinalBuilder variables. That can easily be worked around with some simple scripting, in the BeforeAction script event (javascript):

Another option is to use Property Sets to provide the source of the Version Info. Property sets are especially useful when you have multiple actions that need the same version info, or at least to share the same version numbers. Creating a Property Set is trivial, just drop a PropertySet Define action on your target, before the Delphi Action. In the PropertySet Define action, select Win32 Version Info to manage all version info properties, or Win32 Version Numbers to have the property set just manage the major, minor, release and build numbers.

To set the property set values, add a PropertySet Assign Values action before the Delphi action.

Then in the Delphi action it's a simple task to select the property set in the version info tab

Notice that the version number fields are disabled, since they are now provided by the property set. If you choose the Win32 Version Info property set type, more fields are disabled.

One last thing I should mention, is that along with the Version Info and the MAINICON, the project.res file also typically (well for windows at least) contains the manifest file. I recommend you look at the Resource Compiler tab, where it lets you choose which resource compiler to use (more useful in older versions of delphi, where brcc32 didn't cope with some hicolor icon types) and specify the manifest file. I discussed windows manifest files a few years ago in this blog post.

Introducing Continua CI Version 1.9

Tue, 14 Aug 2018 13:47:08 GMT

Version 1.9 is now out of beta and available as a stable release. Thank you to those of you who have already tried out the beta - especially those who reported issues.

This version brings major changes to the notifications system. We redesigned it using a common architecture, that makes it much easier to add new notification publisher types. Where previously, only email, XMPP and private message notifications were available, there are now publishers for Slack, Teams, Hipchat and Stride. And we can now add more (let us know what you need).

We are no longer limited to one publisher of each type. You may, for example, have different email servers for different teams on your company. You can set up two email publishers, one for each server, and set up subscriptions so that notifications from different projects go to different email servers. Likewise for different Slack workspaces, Teams channel connectors and so on.

We have also improved the XMPP publisher to support sending notifications to rooms. Subscriptions have been improved, allowing you to specify a room and/or channel for this and other publishers.

User preferences have been updated allowing each user to specify a recipient id, username or channel per publisher.

You can see some metrics on the throughput of each publisher (number of messages on queue, messages sent per second, average send time, etc.) on the Publishers page in the Administration area. This also shows real-time counts of any errors occurring while sending messages and also any messages waiting on a retry queue due to rate limiting or service outages. This allows you to know when you need to upgrade rate limits or make other service changes.

The Templates page has been updated. Templates are now divided into a tab per publisher. The list of available variables for each event type has been moved to a expandable side panel.

This release is built on .Net Framework version 4.7.2, which has allowed us to upgrade a number of third party libraries, including the database ORM and PostgreSQL drivers. This has noticeably improved performance, as well as providing us with a richer platform to build future features on. The setup wizard will prompt for you to install .Net Framework version 4.7.2, before continuing with the installation.

Note that applications running on .Net 4.7.2 do not run on versions of Windows prior to Windows Server 2008R2 and Windows 7 SP1. We are also dropping the 32-bit server installer. This is mainly to reduce testing overheads. We will still be releasing 32-bit agents for those who are using 16-bit compilers.

We will continue to provide bug fixes to Continua CI version 1.8.1 for while to give you time to migrate from older platforms.

Continua CI and TLS 1.2

Fri, 23 Feb 2018 09:24:09 GMT

SSL standards are changing, and older SSL/TSL protocols are slowly being deprecated, or even turned off by some services. This post shows how to enable TLS 1.2 support in Continua CI.

Yesterday, we started getting reports that the Github Status event handler, and the Github Status action in Continua CI had stopped working.

Sure enough, in our testing here we were able to confirm the case. While testing this under the debugger, the error we were seeing was rather strange : "The request was aborted: Could not create SSL/TLS secure channel.".

After some research, we found this error was due to being unable to negotiate a common protocol between the client and the server.

Now Continua CI 1.x is built with .NET 4.0 (v2 will be on 4.7.1) - we know that .NET 4.0 doesn't support TLS 1.2, and a quick check of the github api server using SSLLabs shows that they now only support TLS 1.2.

I wondered if this was announced by github - turns out they did announce this 3 weeks ago :

Weak cryptographic standards removal notice

and yesterday they permanently disabled TLS 1.0 and 1.1

Weak cryptographic standards removed

Anyway, back to Continua CI. The good news is that there is a way to enable TLS 1.2 support in Continua CI. Note that this only works when running on Windows Server 2008 or later (Server 2003 does not support TLS 1.2 at all, and we will be dropping support for it with v2).

1) Install .Net Framework 4.5 or later - since all 4.x frameworks effectively replace 4.0 - 4.5 has support for TLS 1.2

2) Edit %ProgramFiles%\VSoft Technologies\ContinuaCI\Server\Continua.Server.Service.exe.config on the server and %ProgramFiles%\VSoft Technologies\ContinuaCI Agent\Continua.Agent.Service.exe.config on each agent - add the following line in appSettings section :

       <add key="Continua.Service.SecurityProtocolType" value="Tls|Tls11|Tls12" />

Note that the key supports the following values: Ssl2|Ssl3|Tls|Tls11|Tls12|Default

Default = Ssl3|Tls
Multiple protocols can be separated with |
The value "Tls|Tls11|Tls12" will allow Continua CI to work with services that do not support or have not enabled TLS 1.2, and with services that only support TLS 1.2 .

3) Open Regedit and add the following value to : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 : SchUseStrongCrypto type DWORD value 1

4) Restart the Server and Agent Services.

5) You may need to restart your server(s) for the registry change to take effect.

One last note : This change also effects the communication between the Continua CI Server and agents, if you make the change on the server, make sure you make a compatible change on the agents.

Windows 10 Fall Creators Update

Tue, 17 Oct 2017 09:55:38 GMT

The Windows 10 Fall Creators Update has only been out a few hours, but we're already getting questions about it.

In our limited testing, FinalBuilder 8 and Automise 5 run fine.

I've only been running the Fall Update for a few hours, but so far I have not noticed any issues. The applications I use daily all run fine.

The "Windows 10 Creators Update" (ie the one before the Fall Update - stupid release naming imho) broke the Delphi debugger when using runtime packages. Aparently the issue was caused by a library loader optiimisation, not taking into account that dll's can have multiple import tables. I never did see a full explaination or acknowledgement of the problem from Microsoft.

This only affected the debugger (all native code debuggers, not just Delphi), which would load and unload each dll many times (based on the number of imports, for FinalBuilder's core package, it was in the hundreds). Sometimes the application would launch, only for the debugger to crash, sometimes it would just hang, sometimes the Delphi IDE would get out of memory errors.

For me, this was a big issue, since FinalBuilder and Automise use runtime packages. This affected all versions of Delphi, even the latest 10.2 (Tokyo). Embarcadero did eventually ship an update to 10.2 that mostly resolved the problem (not an easy thing as it involved major linker changes), but that didn't help us as we're using an older version (for reasons I won't go into here!).

So since April 2017, I've been really hamstrung when it comes to debugging. Fortunately we discovered the issue before the Creators Update was installed on our other Delphi development machines (and it's a been a constant battle with windows update nagging to install it ever since) so we were still able debug, just not on my dev machine. Frustrating to say the least.

The good news is that the Fall Update (mostly) fixes the problem. I still see some dlls/packages getting unloaded and reloaded again, but the application launches and I can debug.

As far as windows functionality in the Fall Update goes, well the Task Manager has a new GPU section on the performance tab which is mildly interesting, but since I don't use a Pen, or wear a VR headset while working, I'm not noticing much to get excited about. Hopefully, it's just a lot of bug fixes and performance enhancements, minus the show stoppers!!