unexpected values in Windows RDP certificates depending on the command

Posted by fjleon@reddit | sysadmin | View on Reddit | 3 comments

we have two different tools, maintained and developed by separate teams.

Tool 1 needs to know the thumbprint of the RDP certificate, and uses this method:

$computerName = (Get-CimInstance -ClassName Win32_ComputerSystem).Name

(Get-CimInstance -Namespace "root\CIMV2\TerminalServices" -ClassName Win32_TSGeneralSetting ` -ComputerName $computerName -Filter "TerminalName='RDP-Tcp'").SSLCertificateSHA1Hash

Tool 2 instead uses this method:

$cert_info = Get-ChildItem Cert:\LocalMachine\'Remote Desktop'\ $thumbprint = $cert_info.Thumbprint

We are finding out that if the RDP certificate gets deleted, somehow Tool 1 is still showing the old thumbprint. In other words, it gets cached. The second tool does not show the thumbprint at this point since that's being deleted.

I could not find any hints in the Microsoft documentation that WMI is cached, but other posts do suggest this.

Besides rewriting tool 1 to use the second tool's method, is there any way to get reliable results?

[-]

Dracozirion@reddit

I'm going to assume that the remote desktop service loads the certificate in memory and it stays there it until the service is restarted or until a specific time period is met that cycles it. The second command clearly reads it from the certificate store.

Here's more information. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations

If I delete mine, the same thumbprint stays in the registry as well until I restart the service.

fjleon@reddit (OP)

thank you for your comment. our automation is deleting the RDP cert, then shutting the VM down, making a clone of it, then sysprepping the clone. we do this to prevent any failures from impacting the original VM.

we have found out that if we don't delete the cert, the issue doesn't occur (and nothing bad seems to happen with the original golden image VM). we have also found that this issue only happens if we try to image the VM with citrix vda installed, which we are puzzled about.

looks like we have several options to prevent this from happening

Thanks for reporting back! :)