If you use Microsoft Remote Desktop Services, you may well have come across a dreaded “Invalid Parameter” error when trying to replace the root RDP certificate. Replacing the root certificate gets rid of the issue of the default self-signed certificate causing security errors when connecting to a remote desktop session – this is an especially important task if you use RemoteApp with a Remote Desktop Gateway server, not doing so will cause a break in the login mechanism where Windows will prompt you to make a decision on the handling of the self-signed certificate – annoying when all you want to do is reach your desktop and/or app.
Updating the root RDP certificate is normally achieved by issuing the following command in an elevated command prompt or Powershell session;
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="Thumbprint"
“Thumbprint” is the SSL fingerprint from the SSL certificate you are trying to install as the root RDP certificate. You can get this by viewing the certificate in the Certificates snap-in (if you’ve got that far) or by double-clicking the certificate and checking its values. If you copy/paste from the certificate to something like Notepad, be sure to remove all spaces and any leading characters, there is a hidden character in the Certificates snap-in section for the thumbprint so be sure to strip it out as it’s invisible (leading whitespace).
The following error is common and having spent a while trying to fix this issue using online resources, there is a distinct lack of information on the actual cause of this error which I hope this post addresses.
So, there’s a couple of reasons why this can happen – here’s what to check to ensure you can successfully update your root RDP certificate
Cause number 1: Missing certificate or certificate in the wrong location
The root RDP certificate must be stored in the local store of the computer account.
- Open an elevated command prompt and type “mmc.exe” and press enter. Next click on “File” and “Add/Remove snap-in…” and add the Certificates snap-in
- Choose “Computer Account” from the list and click “Next”
- Choose “Local computer” (the default) and click “Finish”
- Click “OK” to exit the wizard
The Certificates snap-in is displayed. To import the certificate;
- Expand the “Certificates” node then “Personal”
- Click on “Certificates” under “Personal”, right click and select “All Tasks” then “Import…”
- Click “Next” and browse to the location of your certificate
- Enter any additional information required by the wizard (i.e. the password for the private key, if applicable)
- On the Certificate Store page, leave the default certificate store (“Personal”) and finish the wizard.
Run the import command and check the output again, if everything is OK, you’ll see the following, if you get “Invalid Parameter”, continue reading…
Cause number 2: Lack of private key information
This one caught me out; despite having my certificate in the correct location, it had been imported from a .crt file which did not have private key data stored in it. To remedy this, I imported a .pfx version of my certificate that I’d created previously – the .pfx had both public and private key data and so fulfilled the requirement of making the private key data available. If you have a .crt and .key combo (public and private certificate data) then there are tools online that can convert them into a single file with both public and private data (e.g. the .pfx certificate I used) or if you have OpenSSL installed that can be used too.
Cause number 3: Inappropriate SSL certificate
Not all SSL certificates are created equal – to be up for the task of authenticating servers (as is necessary here) the SSL certificate must have the “Server Authentication (184.108.40.206.220.127.116.11.1)” Enhanced Key Usage type. To find out if your certificate has this type, you can either refer to the “Intended Purposes” column in the Certificates snap-in (see the screenshot above – it shows “Server Authentication” as one of the intended purposes) or double-click the certificate, switch to the details tab and find the “Enhanced Key Usage” section. Without “Server Authentication (18.104.22.168.22.214.171.124.1)” – the certificate is not suitable for this purpose.
That’s it – if you have these things checked off, you should have no issues using your certificate as the root RDP certificate and pass-through authentication in your RDS environment should work with no issues.