• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 496
  • Last Modified:

RD Gateway and not being able to purchase SAN Certificates with internal domain names

I am looking for a solution to get around the problem of not being able to purchase a new Subject alternate name SSL certificate (SAN Certificate) that contain internal (not fully qualified) domain names. EG servername.internal.local

Currently I am using a number of TS Gateway setups (or RDS Gateway for those using the new lingo) and have SAN certificates with the public DNS name then with the internal server names listed for the servers that we are connecting to internally.  Now that the CA\Browser forum rules have come into affect CA's are not issuing certificates with internal DNS names.

The last thing I want to consider is changing the internal domain name and I don't want to use self signed certificates as a number of these are accessed by people that I do not control their desktops.

Does anyone have any ideas?  Is there a way to change Gateway services to not use the internal server name but an external name using DNS trickery?

Thanks in advance.
0
Dave_IT_Fellow
Asked:
Dave_IT_Fellow
  • 2
1 Solution
 
JAN PAKULACommented:
modify that


C:\Windows\system32\drivers\etc\hosts
you need to run the editor (eg. notepad) as administrator, which you do by locating it through the Start menu and then right clicking on the editor's icon, then manually open and edit the hosts file.

#      127.0.0.1       localhost
#      ::1             localhost

You can setup as many host names as you like all pointing to your localhost, each in most cases should be accessible with the ip, 127.0.0.1.

For example:

 127.0.0.1               local.project1
 127.0.0.1               local.project2
 127.0.0.1               youcanuseany.name.here


or like you said modify local domain to match external domain (i use that myself)  ans use Split DNS

http://www.youtube.com/watch?v=yPH02ZcfFtc
0
 
Dave_IT_FellowAuthor Commented:
Thanks for your reply,  but I have found the answer.  

My TS Farm settings needed to be externally resolvable (ts.domain.com instead of ts.domain.local),  then using a standard SSL Certificate it no long prompts with an error in the certificate name vs the server name.

This removed the requirement for needing a SAN certificate.
0
 
Dave_IT_FellowAuthor Commented:
I found the solution reading further forum posts saying that my TS farm name should be the same as my SSL certificate.

I tested this in a clean environment and the solution works perfectly using approved Microsoft methods.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now