Good morning AskPerf! Kiran here with a question for you: Why do we need certificates? Well, certificates are used to sign the communication between two machines. When a client connects to a server, the identity of the server that is receiving the connection and in turn, information from the client, is validated using certificates.
This is done to prevent possible man-in-the-middle attacks. When a communication channel is setup between the client and the server, the authority that issues/generates the certificate is vouching for the server to be authentic.
So, as long as the client trusts the server it is communicating with, the data being sent to and from the server is considered secure. This brings me to the next question:
What type of certificate is required for RDS?
The following blog contains information regarding the type of certificates and how you can create them using the Internal CA of the domain.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
Basic requirements for Remote Desktop certificates:
- The certificate is installed into computer’s “Personal” certificate store.
- The certificate has a corresponding private key.
- The "Enhanced Key Usage" extension has a value of either "Server Authentication" or "Remote Desktop Authentication" (1.3.6.1.4.1.311.54.1.2). Certificates with no "Enhanced Key Usage" extension can be used as well.
As the function it performs suggests, we need a ‘Server Authentication’ certificate. This certificate can be generated using the ‘Workstation Authentication’ template (if required).
Here is the exact process:
- Open CERTSRV.MSC and configure certificates.
- Open Certification Authority.
- In the details pane, expand the instructor computer name.
- Right-click Certificate Templates and select Manage. Right-click Workstation Authentication and click Duplicate Template.
- On the General tab, change the Template display name to Client-Server Authentication and check Publish certificate in Active Directory.
- On the Extensions tab, click Application Policies then Edit. Click Add then select Server Authentication. Click OK until you return to the Properties of New Template dialog.
- Click the Security tab. For Domain Computers, click the checkbox to ‘Allow Autoenroll’. Click OK. Close the Certificate Templates Console.
- In the certsrv snap-in, right-click Certificate Templates and select New then Certificate Template to Issue.
- Select Client-Server Authentication and then click OK.
This will be visible when viewing the certificate in the ‘Certificates’ MMC snap-in, as below:
When you open the certificate, the ‘General’ tab will also contain the purpose of this certificate to be ‘Server Authentication’ as seen below:
Another way to validate this, would be to go to the ‘Details’ section of the certificate and look at the ‘Enhanced Key Usage’ property:
The easiest way to get a certificate, if you control the client machines that will be connecting, is to use Active Directory Certificate Services. You can request and deploy your own certificates and they will be trusted by every machine in the domain.
If you're going to allow users to connect externally and they will not be part of your domain, you would need to deploy certificates from a public CA. Examples including, but not limited to: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Now that you know what type of certificate you need, let’s talk about the contents of the certificate.
In Windows 2008/2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, next to the connection broker and finally to the server that will host your session.
In Windows 2012, you connect to the Connection Broker and it routes you to the collection by using the collection name.
The certificates you deploy need to have a subject name or subject alternate name that matches the name of the server that the user is connecting to. So for example, for Publishing, the certificate needs to contain the names of all of the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN of the URL, based on the name the users connect to. If you have users connecting externally, this needs to be an external name (needs to match what they connect to). If you have users connecting internally to RDweb, the name needs to match the internal name. For Single Sign On, again the subject name needs to match the servers in the collection.
For our example, let’s consider my RDS deployment to contain the following machines:
RDSH1.RENDER.COM Session Host with Remote Apps configured
RDSH2.RENDER.COM Session Host with Remote Apps configured
RDVH1.RENDER.COM Virtualization host with VDI VMs configured
RDVH2.RENDER.COM Virtualization host with VDI VMs configured
RDCB.RENDER.COM Connection Broker
RDWEB.RENDER.COM RDWeb and Gateway server
When my client connects internally, he will enter the FQDN of the server that hosts the web page, i.e,: RDWEB.RENDER.COM.
The name of the certificate needs to be this name, of the URL that the user will initiate the connection to. But we need to remember that the connection does not just end here. The connection then flows from the web server to one of the session hosts or virtualization hosts and also the connection broker.
The certificate can be common on all of these servers. This is why we recommend that the Subject Alternate Name of the certificate contain the names of all the other servers that are part of the deployment.
In short, the certificate for my environment would be as follows:
Type: Server Authentication
Name: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.RENDER.COM; RDCB.RENDER.COM
This is all you need as long as you have 5 or less servers in the deployment. But we have a problem when we have more servers in the deployment. This is because, by design, the SAN (Subject Alternate Name) on a certificate, can only contain 5 server names. If you have more of them, you will have to get a wildcard certificate issued to cover all the servers in the deployment. Here my certificate changes as follows:
Type: Server Authentication
Name: RDWEB.RENDER.COM
SAN: *.RENDER.COM
We still do encounter some challenges when it comes to the following scenario. Note, that this is true only when you have external users that access the deployment.
External name: RDWEB.RENDER.com
Internal Name: RDWEB.RENDER.local
Here, if you get a certificate with RDWEB.RENDER.COM in the name, the certificate errors still do appear. This is because the certificate is supposed to validate a server with the FQDN: ‘RDWEB.RENDER.COM’. However, your server is ‘RDWEB.RENDER.LOCAL’ and the ‘.com’ to ‘.local’ magic only happens at your public firewall/router using port forwarding (most common scenario).
In such scenarios, we previously recommended that the name on the certificate contains the ‘.com’ name and the SAN contains the ‘.local’ name.
Recently, all public certificate providers are stopping issuing certificates with ‘.LOCAL’ in them. Starting with Windows 8 and Windows Server 2012, we no longer need the external and internal names to be contained in the certificate.
In scenarios where you have external clients connecting in and you have a private internal domain suffix (DOMAIN.LOCAL), you can get a certificate from a Public CA with the external (RDWEB.DOMAIN.COM) name and bind it to the RD Web Access and RD Gateway roles, because these are the only roles that are exposed to the internet. For RD Connection Broker – Publishing and RD Connection Broker – Enable Single Sign On, you can make use of an internal certificate with the ‘DOMAIN.LOCAL’ name on it. This however, as mentioned earlier, will only work with clients connecting through RDC 8.0 or above.
The RD Gateway and Remote Desktop Client version 8.0 (and above) provides the external users with a secure connection to the deployment. Once connected to the deployment, the internal certificate with the ‘.local’ name will take care of Remote App signing (publishing) and Single Sign-On.
Now, lets look at where we configure the certificate we have:
Open the Server Manager on the Connection Broker server and Click on Remote Desktop Services in the left-most pane.
Once here, you will see your deployment shown as in the illustration below. Click on Tasks and select “Edit Deployment Properties”
This will bring up the property sheet of the deployment. Select the Certificates option in the left pane:
Now, as discussed earlier, you can select the certificate that was created using the ‘Select Existing Certificate’ button on the bottom of the screen.
Just point it to the ‘.pfx’ file and allow it to import the certificate for the role.
You can use a single certificate for all the roles, if your clients are internal to the domain only, by generating a simple wildcard certificate (*.RENDER.LOCAL) and binding it to all the roles.
Note, that even if you have multiple servers that are part of this deployment, the Server Manager will import the certificate to all the servers in the deployment, place them in the trusted root of the machines and bind them to the respective roles.
-Kiran Kadaba