RDP web certificate error

#1

After the first renew of my certififcate RDP still works correctly when connecting directly and also the website shows the newly generated SSL-Certificate.

sadly I can’t connect through RDWEB till I reboot the whole Server… Restarting single services didn’t help.
maybe I just didn’t found the right service. Does someone have an idea?
Info → It’s running on only a single 2019 Server. without Gateway! (yes this works)

#2

Hi, which services did you restart? Did you use a service restart in your script or in a Service Stop/Start/Restart deployment task? I agree it’s quite difficult to automated as you are generally connected to that service at the same time as trying to automate the cert!

#3

Hey there

now getting the same problem again, but rebooting doesn’t help.
I verified that the cert in the webbrowser has the same fingerprint as the cert which is shown…
I also imported it like this:
Import-RDWebClientBrokerCert
but smh not working.

#4

So I’m not an RDP expert but here is our built-in deployment task code for RDP Gateway (Tasks > Add Deployment Task)- note that if you want to restart services you need to enable that in the task parameters UI and I would recommend using the Manual trigger type so you can run the task during a maintenance window if it will interrupt other users.

I don’t know if it applies to your version/configuration and some users prefer to script their own. It works in the 2016 version I tested when developing this script in a simple environment (no other machines involved):

param($result, [switch] $restartServices = $false)

Import-Module RemoteDesktopServices

# Apply certificate
Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop

# Optionally restart TSGateway and related service

if ($restartServices -eq $true)
{

	Restart-Service IAS -Force -ErrorAction Stop
	Restart-Service TSGateway -Force -ErrorAction Stop
	Restart-Service SSTPSvc -Force -ErrorAction Stop
	Write-Host "Services Restarted."
}

In general, if a service is using IIS for it’s website then by default Certify will take care of the IIS side, but for other things you need to ensure you are applying the new certificate thumbprint etc to the service.

Sometimes this involves powershell, registry settings, WMI or just copying the file somewhere. Usually you then have to restart the service, as you know. For some services this can get extremely complicated/unpredictable and sometimes the best result is to not apply the new cert until a maintenance windows then do a full reboot, so for instance to make it part of your monthly updates etc.

Some of this stems from not knowing the full dependency chain of services and sometimes it because the service was not designed to change it’s certificate more frequently than about once per year (the old way of doing it before Let’s Encrypt existed), so reboots were normal. If the problem persists (and the built in certify deployment task is not right for you) then I would contact microsoft support to ask them.

#5

thx for the input.

I don’t use a Gateway Server as this is not needed anymore.
The weird thing is, a reboot doesn’t fix the problem (just as restarting all RDP related services)… somehow only waiting a few hours fixes it…
IIS actually uses the new certificate and the error also tells me the new certs fingerprint.
When I check the colletion in the server manager I can see the old certs fingerprint.

Asking M$ about it doesn’t make sense for me as they won’t even talk to me when I pay them 1000$ upfront for a Ticket… they just refund a few weeks later…

#6

I just checked againand somehow the certs fingerprint is shown correctly inside server manager now… but still it won’t accept it when connecting. so this isn’t it yet…

#7

this seems to work now:

param($result)

set-alias ps64 "$env:C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe"

ps64 -args $result -command {

   $result = $args[0]

   $pfxpath = $result.ManagedItem.CertificatePath

   Import-Module RemoteDesktop

   Set-RDCertificate -Role RDPublishing -ImportPath $pfxpath -Force

   Set-RDCertificate -Role RDWebAcces -ImportPath $pfxpath -Force

   Set-RDCertificate -Role RDRedirector -ImportPath $pfxpath -Force

   Import-RDWebClientBrokerCert $pfxpath

   Import-PfxCertificate -FilePath $pfxpath -CertStoreLocation "Cert:\LocalMachine\Root"

}
#8

Thanks, you don’t need the 64 bit powershell wrapper in current version of Certify because it’s always 64-bit now. So:

param($result)

$pfxpath = $result.ManagedItem.CertificatePath

Import-Module RemoteDesktop

Set-RDCertificate -Role RDPublishing -ImportPath $pfxpath -Force

Set-RDCertificate -Role RDWebAcces -ImportPath $pfxpath -Force

Set-RDCertificate -Role RDRedirector -ImportPath $pfxpath -Force

Import-RDWebClientBrokerCert $pfxpath

Import-PfxCertificate -FilePath $pfxpath -CertStoreLocation "Cert:\LocalMachine\Root"

I’m not sure about the purpose of that last line with the local machine root store (it’s already stored under LocalMachine\My) is there something somewhere that says the cert needs to be in that store? If so I’d do that first in the script.

#9

I’m not sure what the problem is but I actually need to run the script two times before it works. There needs to be a wring order.
moving

Import-PfxCertificate -FilePath $pfxpath -CertStoreLocation "Cert:\LocalMachine\Root"

→ first line won’t fix it.

sadly I’m currently not really able to test this throug, so I just add the task 2 times…
What’s really great… I don’t need no restarts of anything and when someone is logged in it won’t kick him out!

#10

Hmm, I have actually seen a similar issue on windows before it’s something to do with ephemeral private key storage. Certify actually stores the same cert twice to reduce the likelihood of encountering the problem.