Starting with Windows Server 2003 SP1, it is possible to provide server authentication by issuing a Secure Sockets Layer (SSL) certificate to the Remote Desktop server. This is easy to configure using the “Remote Desktop Session Host Configuration” tool on Server operating systems. Though no such tool is available on Client operating systems such as Windows Vista and Windows 7, it is still possible to provide them with certificates for Remote Desktop connections. There are two possible ways to accomplish this. The first method is using Group Policy and Certificate Templates, and the second one is using a WMI script.
[April 15, 2010: Updated to correct which certificates can be used.]
This method allows you to install Remote Desktop certificates on multiple computers in your domain but it requires your domain to have a working public key infrastructure (PKI).
First, you need to create a Remote Desktop certificate template.
The new template is now ready to use.
The next step is to publish the template.
Now the “RemoteDesktopComputer” template is published and can be used in certificate requests.
The last step is to configure Group Policy to use certificates based on the “RemoteDesktopComputer” template for Remote Desktop authentication.
Note: The following steps create the new policy to apply to all computers in the domain, but it can also be scoped to an Organizational Unit if needed.
This method allows you to use a server certificate of your choice with Remote Desktop connections but the certificate needs to be manually installed on the computer first. For example, this method can be used if you bought your certificate from a public certificate authority.
First check that your certificate meets the requirements for Remote Desktop certificates. Certificates that don’t meet these requirements won’t work and will be ignored.
In order for a certificate to be used for Remote Desktop connections you first need to obtain the certificate’s thumbprint.
Now you have the thumbprint string ready to use. It should look like this: 0e2a9eb75f1afc321790407fa4b130e0e4e223e2
Once you have the thumbprint you can use the following script to cause the certificate to be used for Remote Desktop connections.
var strComputer = ".";
var strNamespace = "\\root\\CIMV2\\TerminalServices";
var wbemChangeFlagUpdateOnly = 1;
var wbemAuthenticationLevelPktPrivacy = 6;
var Locator = new ActiveXObject("WbemScripting.SWbemLocator");
Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;
var Service = Locator.ConnectServer (strComputer, strNamespace);
var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");
if (WScript.Arguments.length >= 1 )
TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);
TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";
To run this sample, copy/paste the above code into a “rdconfig.js” file, start cmd.exe as the Administrator, and then run the following command: “cscript rdconfig.js <thumbprint of your certificate>”. Running this script without a parameter will revert Remote Desktop back to using the default self-signed certificate.
Thanks, Sergey, for the hint.
The security tab of my certificate template permits nobody to autoenroll, yet the automatic renewal happens when the renewal period is reached (6 weeks by default). At the moment I don't know if it's possible to exclude a specific template from auto renewal. Should I shorten the renewal period than a certain duration?
And yes, the template has the same Template/Display names, so there has been no problem until renewed.
If the "Autoenroll" permission was not set, then the certificate could not have been renewed through the auto enrollment process. Most likely the new certificate was obtained by the Remote Desktop component but then something had prevented it from applying the certificate to the RDP-Tcp listener. It could be that computer account did not have “Read” permission to the template (read permission is required to obtain the template OID, which is then used to verify if the certificate was issued based on the specified template).
I’d check if your computer account has Read and Enroll permissions to the template (Note: you need to re-issue the template every time you change it). Then to verify that it works, I’d delete the certificate and then restart the SessionEnv service. If everything is configured correctly, after the service is restarted you should see RDP-Tcp connection configured with a new certificate. If not, you can check the System event log for error messages.
I created a template as documented above but I cannot seem to publish it. When I select "New\Certificate Template to Issue", the new template does not appear in the list. I am logged on to CA server which is 2003 R2 Enterprise SP2.
Cancel - I figured it out. I hate when I'm brought into a project halfway through :)
For the duplicate certificates issue, it seems to be a known issue, check this url social.technet.microsoft.com/.../382774a9-5b2c-4d54-9abb-03357adccc08
To those people who are using 'Part II: Using a WMI script' and getting the "SWbemObjectEx: Invalid parameter" error:
It took me a little bit to figure out what was going on, but it seems blindingly obvious now that I've found the problem - when you go to import your certificate (from an external Certificate Authority or whatever), you need to be careful to import the certificate into the Computer's account certificate store, *not* your user account one which Windows seems to default to in many cases.
Once the certificate is in the right location things work just fine.
Its also possible to use Smart Cards. I have seen someone said that it will not going to work. I have recently implemented this for a cloud. RDP Clients do support smart cards. There are some built in certificates for smart cards. Through a careful implementation, enrollment (or key distribution) and Revocation list distribution, this become possible. The smart card has to have an interface that can inject the card to the device.
Any reason to use this RDP Template, instead of just a simple V2 Computer certificate? Pros and Cons?
"Computer" template will work with Windows 8 and 2012 Server, but won't work with earlier OS versions because of a bug they have that require template name and template display name to be the same. "Computer" template has "Machine" for the template name.
In Windows 8 and Windows Server 2012 configuring Remote Desktop certificates has become easier:
1. It is no longer required for the template name and template display name to be the same.
2. You no longer need to create a custom template. One of the built-in templates, for example “Computer” template, can now be used with Remote Desktop.
3. The “Server Authentication Certificate Template” group policy setting can now contain either one: template name (CN), template display name or template object identifier (OID). The latter is more reliable because template name can be changed while OID cannot. Certificate templates that support Windows 2000 CAs (schema version 1) do not have OIDs, so with those templates you can use their template name (CN). Using template display name should be avoided because this name does not uniquely identify the template – multiple templates can have the same display name.
I have tried doing this a 100 different ways issuing certificates from my internal CA. It doesn't seem to matter how I do it I still can't use rdpsign to sign my custom remote desktop files. When I run RDPSign I get "Unable to use the certificate specified for signing. Error Code: 0x80070490. I have made new certs and reimported. I have literally done everything I could think of. I tried option 1 and option 2. Still nothing. One thing to note, if I sign a remote app from the console using the certificate I issued it works like a dream - it just won't work from rdpsign which is what I need as I want to publish a custom rdp connection on users desktops. Any help would be greatly appreciated.
Ignore the last post, for some reason the RDP file was corrupt. As soon as I replaced it and reran the file all worked just fine.
HomeCloset - this definitely looks like a bug to me, so thanks for your tip. You can actually just delete the registry setting you mention then restart the "Remote Desktop Configuration" service - this will recreate the setting with the correct thumbprint and everything will spring back into life. We've added a domain startup script to delete the setting and restart this service.
I am getting the following error:
C:\rdconfig.js(38, 1) SWbemObjectEx: Invalid parameter
Hi - is it possible to include a SAN in the Server Auth cert?
I have managed to complete the process including GPO, custom cert template etc. All servers are getting the new certs and its binding to the RDP service replacing the auto generated cert but name mismatch warnings are displayed during an RDP connection attempt as the cert subject is the server internal FQDN.
Users are connecting to the server short name, can this be included in the SAN field to avoid the name mismatch warning?