Deploy to RDP Gateway Service Unsuccessful

I’ve been running this service for some time, but today, my users are facing issues launching apps via RemoteApp. They encounter the following error message: “The digital signature of this RDP File cannot be verified. The remote connection cannot be started.”

I’ve conducted a thorough check and reissued the certificate, and there don’t seem to be any issues. Certify confirms that everything is in order.

I even attempted to redeploy the certificate to the RDP gateway using a task, but the problem persists, and it still indicates that the certificate has expired when I inspect the Certificate table under deployment properties.

Why aren’t they updating automatically? Is there a manual method to update them?

I’m not a RD Gateway administrator but are you able to access any of the services via a web browser? e.g. RD Web Access. The point was to confirm that the certificate is valid. We’ve never seen this particular error and people have been using the app to create certificates for remote desktop for years. Which deployment task are you using?

Has everything been recently restarted? Just wondering if the services could be holding onto an expired certificate.

If you could share a link to any website that we could check that would help us see the problem.

Another thing you could try is to manually deploy the certificate to see if that fixes the problem, you can locate the latest certificate under C:\programdata\certify\assets

As an aside I do remember a similar sounding problem a while back that was something to do with the servers own self-signing of RDP connection files and the fix was to re-issue the RDP connection file. This was nothing to do with the domain certificates, it was some sort of RDP signature feature.

Certainly, I can access the apps page via the browser, but I encounter the error when I try to launch the App. I’m utilizing the Deploy to RDP Gateway Service.

Yes, I’ve attempted restarting multiple times, but unfortunately, it hasn’t resolved the issue.

Thank you, this solution did the trick. I had to manually apply the certificate to all four services, restart the machine, and then generate a new link for the users. It was a bit of a hassle, but at least it’s functioning now. I’m hoping I won’t have to go through this process again in the next 30 days.

No, I’ve heard of it once several months ago on a reddit forum post and none of the administrators could really explain it but from my interpretation when you issue the RDP file it’s signed by the server, probably using a self signed certificate, and that signing seems to be valid for months or years? Probably best to speak to Microsoft to get a firm explanation on how their RDP signing works.

We do provide a basic task for RDP related deployment, which uses this powershell script: but you can see it doesn’t do very much. If this is one you have been using then it hasn’t really changed much over the years except we recently added more options for the account/logontype being used to run the task. That will depend which version of the app you are using.

You do also have the option of performing more sophisticated deployment using your own scripting: Scripting | Certify The Web Docs

You should definitely review this after the next renewal to check that everything is going OK and that the certificate being presented in your web browser is the latest renewed cert (and not this last one), which you will be able to tell by the certificate start date.

I am waiting to test this out, so no guarantee it will actually work but if not, you will be a lot closer to your goal. I’ve put a couple of links in the header comment block. In theory it will cycle through the four roles in a RDS deployment and set the cert using the thumbprint of the last generated LE cert.

Pop this script on the server somewhere and run it as a deployment task, Powershell script.

Update the RD role certificate from Certify the web (Lets Encrypt)

JG 12 Oct 2023


if ($result.IsSuccess) {

    $rdbroker = Get-RDServer -Role RDS-CONNECTION-BROKER
    $rdbrokername = $rdbroker.Server.ToString()

    $roles = @(

    ForEach ($role in $roles)
        Set-RDCertificate -role $role -Thumbprint $result.ManagedItem.CertificateThumbprintHash -ConnectionBroker $rdbrokername -Force
1 Like

@gerdesj cool script! Do all remote desktop deployments have a broker and a gateway or does it vary?

For this particular issue the step of generating a new link for users seems to be the key and I still theorize (until disproven!) that it’s a self signed cert unconnected to the service certificates that’s doing the rdp file signing (and that’s expiring etc).

The broker seems to be compulsory but a gateway isn’t. The gateway is basically a https to RDP proxy.

It’s the usual MS ridiculous presentation. You have that awful Server Manager thing, a random assorted mmc based thingies and disgracefully bad documentation.

You search for help and end up in the usual mire of sites with names like geeksforgeeks or even worse - the MS social thing, where you will be told to run sfc /scannow and other annoying crap.

cough sorry, went off on one. When you run the deployment wizard thing, you get the option to not have a gateway. At the end you have the four “roles” that need a SSL cert. When you set all four to a trusted cert then instead of an orange “error” style “do you trust …” you get a blue one instead, which looks a bit less nasty.

1 Like