Help with understanding Windows 2008 RDS Certificate requirements.

I have setup a RDS System which works well internally but I now need to open access to this externally.

Our system consists of:-
1x Broker and Licensing Server
1x Gateway /Web Access Server
1x Session Host Server (I may add another in the future and farm them)
3x Virtual Host Servers.

Potentialy 75-100 XP Pro SP3 VM's in various Pools

The Gateway’s internal IP is routed through our firewall to an external IP which will be linked to an External DNS record example “”

Understanding Certificates is my problem.

At the moment I have a self signed cert for internal use but it is annoying to be told that its not secure and/or the publisher is unknown. I have read that I would probably need a SAN/UCC cert containing the FQDN’s of all servers in the RDS setup. Our internal Domain name will be different to the Gateway’s external DNS domain record “” Does this matter or will the SAN/UCC cope with this?

This is a first for me with the concept of certificates so if this is a silly question or I have completely misunderstood how this works, my apologies.

If someone could point me the way that would be fantastic. My aim is to have internal and external access with Green URL's Windows and no security prompts regarding certs.

Many thanks
Who is Participating?
tigermattConnect With a Mentor Commented:

>> My question is can I setup internal DNS records mapped to the various RDS Servers IP's and or FQDN's and use our wildcard cert for these

There's no reason to say you can't do that, as long as the internal name you use for the farm is set in your internal DNS, and isn't resolvable in external DNS. Logging in to the farm would then be via the record, but that record must only be resolved at the Gateway once the traffic hits the internal network.

What you don't want to happen is external clients (which need to route through the RD Gateway) resolving the supposedly "internal" name from outside the network. If the "internal" farm name resolves for them, the "bypass RD Gateway for local addresses" option (which is enabled in RD Gateway settings by default) kicks in, because the system thinks it can route right through to the farm on port 3389 without passing traffic through the gateway. This scenario could cause slow downs and/or failed connections and so it's something to be careful to avoid. :)

In theory, the latter option - names in your external DNS namespace for each server, but created in internal DNS only and added to a SAN certificate - would work too. However if you have the wildcard certificate I'd use that - ultimately that will be less cost and less maintenance for you.


You're correct in thinking that a SAN/UCC certificate is the easiest way out of this. My recommendation would be GoDaddy, where they are incredibly cheap:

>> Our internal Domain name will be different to the Gateway’s external DNS domain record “” Does this matter or will the SAN/UCC cope with this?

That really depends on how you configure access to the RD Gateway and RD Web Access.

By far the easiest (and my preferred) solution is to configure split DNS, so will resolve to the Gateway server regardless of whether the user is situated inside or outside the network. Users only need to learn one name and it means you don't need multiple names on the certificate.

To achieve that, you need (if you haven't already) a forward lookup zone for in your internal DNS, then A or CNAME records which map the "remote" record to the internal IP/name of the gateway server.

So in your certificate request you need to include the names of your Session Host server (the full internal name, i.e. server.DOMAIN.local), the RD Gateway FQDN and the RD Web Access FQDN, if they are different. If using split DNS, you only need the external names for the latter two.

I can't speak for the virtualisation hosts as I've not worked with those and we don't use a Connection Broker in our deployment, but a quick search of the Technet documentation suggests the former doesn't require any SSL certificate provision, and the latter needs one for signing purposes.

Once you have your certificate, you need to import it into all the servers (with the private key) and then configure it: in RD Gateway properties, in the RemoteApp console (for signing), and in the RD Session Host server as the certificate to sign the connections with. I can provide specific instructions if necessary but this step is fairly obvious once everything is in place.

With properly configured split DNS and certificates, everything should connect up without any warning messages and SSO will also work correctly when launching RemoteApps via RDWeb.

WycombeAbbeyAuthor Commented:
Hello Matt

Thank you very much for your informative reply. It’s a lot clearer to me on what I have to do now.

Im putting these steps in motion and will report back in the next few days once the external DNS record is setup and I have purchased and installed the Certificate.

WycombeAbbeyAuthor Commented:
Hello Matt

I have had some trouble ordering the cert as our internal domain is on a .net which is viewed as a public domain by DigiCert. The problem here is that an external company setup our network some 5-6 years ago and own the domain name. So I have to get a letter from them stating that our internal domain is ours (in theory) as a whois lookup states otherwise.

In the meantime I have found that we own a wildcard domain cert that’s covers our external domain name.

My question is can I setup internal DNS records mapped to the various RDS Servers IP's and or FQDN's and use our wildcard cert for these or setup internal DNS records for each server and use these names in a SAN/UCC cert so that our internal domain name is not an issue anymore ?

I’m hoping this makes some sense.

Thank you
WycombeAbbeyAuthor Commented:
Thank you Matt for you help on this.

I believe I now have enough information to finish this project.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.