none
TS Gateway - Certificate error

    Question

  • Hello,

    I've installed a lab longhorn server with DC, root-CA and TS gateway roles;

    When I try to connect to this server with RDP client 6 and using TS gateway configuration, I've got the error : the computer cant connect to the remote computer because the terminal services server address and the certificate subject name do not match

    How to change the subject of certificate ?

    Any Idea ?

    thanks

    Monday, December 4, 2006 5:47 PM

Answers

  • I see many people have the same problem. I did everything as "TS Gateway Server Setup Guide Step.doc" and http://www.msterminalservices.org/articles/Overview-Longhorn-Servers-Terminal-Service-Gateway-Part1.html

    I think problem is with import correct certificate to client. Anybody can help us and will write correct instruction step by step "how generate certificates on Longhorn and after import certificates on Vista"? 

    Sunday, December 10, 2006 2:12 PM
  • Quick steps:

    1) issue a cert that matches the externally addressable FQDN of the gateway.

    2) ensure the issuing authorities cert is exported to the client (this is the step most people get wrong, they export the gateway certificate by mistake) this MUST be imported into the trusted root store of the client machine (use the MMC snap in to do this). If the cert goes into the wrong store (usually machine personal or user personal) drag and drop it from that store into the machine trusted root authorities store.

    3) ensure you haven't turned on require certificate auth for the terminal server (this is the default and will mean one less set of certs - to make it easier for testing).

    4) do not use wildcard certs

    let us know if that helps.

    Tuesday, December 19, 2006 12:22 AM
    Moderator

All replies

  • I see many people have the same problem. I did everything as "TS Gateway Server Setup Guide Step.doc" and http://www.msterminalservices.org/articles/Overview-Longhorn-Servers-Terminal-Service-Gateway-Part1.html

    I think problem is with import correct certificate to client. Anybody can help us and will write correct instruction step by step "how generate certificates on Longhorn and after import certificates on Vista"? 

    Sunday, December 10, 2006 2:12 PM
  • Quick steps:

    1) issue a cert that matches the externally addressable FQDN of the gateway.

    2) ensure the issuing authorities cert is exported to the client (this is the step most people get wrong, they export the gateway certificate by mistake) this MUST be imported into the trusted root store of the client machine (use the MMC snap in to do this). If the cert goes into the wrong store (usually machine personal or user personal) drag and drop it from that store into the machine trusted root authorities store.

    3) ensure you haven't turned on require certificate auth for the terminal server (this is the default and will mean one less set of certs - to make it easier for testing).

    4) do not use wildcard certs

    let us know if that helps.

    Tuesday, December 19, 2006 12:22 AM
    Moderator
  •  Ok,

    My problem comes from step 1.

    I successes with self-signed certificates but I wish to use a root CA. I cannot request web server certificate to specify the externally addressable FQDN of my gateway.

     

    Tuesday, December 19, 2006 3:11 PM
  • If I am reading this correctly Export the Certificate from the TS Gateway MMC

     

     

     Vinc_FR wrote:

     Ok,

    My problem comes from step 1.

    I successes with self-signed certificates but I wish to use a root CA. I cannot request web server certificate to specify the externally addressable FQDN of my gateway.

     

    Tuesday, January 23, 2007 7:04 AM
  • I too have this same problem.  I read that maybe you should install active directory certificate services but that errors out when i add it.  If someone has a better way, please share.  I am so very close to getting it to work.  But I also get the cert error.  This does mean that i'm getting a connection?  Has anyone tried to get this to work via the TS Web route?  If so do you have any documentation that could help?
    Tuesday, February 13, 2007 7:10 PM
  • We understand that creating and mapping a self-signed certificate for TS Gateway server role is not easy to do and involves many manual steps. 

    Here are the detailed steps:

    Create and Import a Self-Signed Certificate

    If your company does not maintain a PKI, you can also create and import a self-signed X.509 certificate for your TS Gateway server by using IIS 7.

    To create and import a self-signed certificate

    1.   On the TS Gateway server for which you want to create a self-signed certificate, open Internet Information Services (IIS) Manager. To open IIS Manager, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

    2.   In the console tree, browse to <Local TS Gateway Server>.

    3.   In the details pane, under IIS, double-click Server Certificates.

    4.   In the Actions pane, click Create Self-Signed Certificate.

    5.   On the Create Self-Signed Certificate page, type a name for the certificate, and then click OK.

    6.   The name of the certificate that you created will appear in the list of server certificates.

    7.   To finish configuring your TS Gateway server, proceed to Map the TS Gateway Certificate in this guide and complete the steps that follow.

     

    Install the TS Gateway Server Root Certificate on the Terminal Services Client

    Your computer must verify and trust the identity of the TS Gateway server before you can send your password and logon credentials securely and complete the authentication process. To establish this trust, the clients must trust the root of the server’s certificate. That is, clients must have the certificate of the certification authority (CA) that issued the server certificate in their Trusted Root Certification Authorities store. You can view this store by using the Certificates snap-in.

    This procedure is not required, for example, if a VeriSign or other non-Microsoft trusted public key infrastructure (PKI) certificate is installed on the TS Gateway server, and the Terminal Services client computer trusts the certificate. For more information, see "Obtain a Certificate for the TS Gateway Server" in the Windows Server “Longhorn” Community Technology Preview (August 2006) Release TS Gateway Server Step-By-Step Setup Guide and Designing a Public Key Infrastructure (http://go.microsoft.com/fwlink/?LinkId=4735).

    If the TS Gateway server is using a non-Microsoft, trusted PKI certificate that is recognized and trusted by your client computer, proceed to the Configure Remote Desktop Connection Settings section.

    Important

    Do not install certificates from any untrusted sources or individuals.

    To install the TS Gateway server root certificate, do the following on the Terminal Services client.

    To install the TS Gateway server root certificate on the Terminal Services client

    1.   Open the Certificates snap-in console. If you have not already added the Certificates snap-in console, you can do so by doing the following:

    ·      Click Start, click Run, type mmc, and then click OK.

    ·      On the File menu, click Add/Remove Snap-in.

    ·      In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, click Certificates, and then click Add.

    ·      In the Certificates snap-in dialog box, click Computer account, and then click Next.

    ·      In the Select Computer dialog box, click Local computer: (the computer this console is running on), and then click Finish.

    ·      In the Add or Remove snap-ins dialog box, click OK.

    2.   In the Certificates snap-in console, in the console tree, expand Certificates (Local Computer), expand Trusted Root Certification Authorities, right-click Certificates, point to All Tasks, and then click Import.

    3.   On the Welcome to the Certificate Import Wizard page, click Next.

    4.   On the File to Import page, in the File name box, specify the name of the TS Gateway server root certificate, and then click Next.

    If you created a self-signed certificate as described in Appendix A of Windows Server “Longhorn” Community Technology Preview (August 2006) Release TS Gateway Server Step-By-Step Setup Guide and installed this certificate on the client, the name of the root certificate that appears in this list would be <COMPUTERNAME> Test Root.

    5.   On the Password page, if you specified a password for the private key associated with the certificate earlier, type the password.

    6.   On the Certificate Store page, accept the default option (Place all certificates in the following store -Trusted Root Certification Authorities), and then click Next.

    7.   On the Completing the Certificate Import Wizard page, confirm that the following certificate settings appear:

    ·      Certificate Store Selected by User: Trusted Root Certification Authorities

    ·      Content: Certificate

    ·      File Name: FilePath\<Root_Certificate_Name.cer>, where <Root_Certificate_Name> is the name of the TS Gateway server root certificate.

    8.   Click Finish.

    9.   After the certificate import has successfully completed, a message appears confirming that the import was successful. Click OK.

    10. With Certificates selected in the console tree, in the details pane, verify that the root certificate of the TS Gateway server appears in the list of certificates on the client.

    If you created a self-signed certificate as described in Appendix A of Windows Server “Longhorn” Community Technology Preview (August 2006) Release TS Gateway Server Step-By-Step Setup Guide and installed this certificate on the client, the name of the root certificate that appears in this list would be <COMPUTERNAME> Test Root.

    In the latest Longhorn build (IDS-2), we have automated these steps for you.   Please give a try with IDS-2 build (it is relased to TAP cusotmers today). If you are not a TAP customers, wait for Beta-3 build and give a try.

    • Proposed as answer by shekhar-nsk Tuesday, November 29, 2016 7:47 AM
    Wednesday, February 21, 2007 8:31 PM
  • Why do wildcard certificates not work?  We pay a premium for wildcard certificates to avoid having to create a certificate for each computer.

    Is it planned to make wildcard certificates work?

    I am using Server 2008 EE RC0 as a TS Gateway and I am trying to connect to an internal XP machine from a Vista machine using that gateway.  I have a wildcard certificate from a third party authority installed on the gateway.  This certificate works fine when connecting directly to the gateway machine via TS but does not work for the gateway service.

    Josh
    Wednesday, October 10, 2007 5:43 PM
  • I just can't get it working with self signed Certificate.

     

    I'm using Server 2008 Beta 3 at the moment, not RC0. Could this be the problem?

     

    RB

     

    Tuesday, October 16, 2007 2:35 PM
  • Hi,

    Please check the information in the Step to step guide for TS Gateway on how to configure TS Gateway to work with self signed certificates. Here is the link:

    http://www.microsoft.com/downloads/details.aspx?familyid=518d870c-fa3e-4f6a-97f5-acaf31de6dce&displaylang=en

     

     If you can't get it working even after that, please let me know the exact settings on TS Gateway that you have on the Server 2008 machine. I can try to help you after getting all the details about how to configured the server.

     

    Thanks,

    Vikash

    Tuesday, October 30, 2007 10:55 AM
    Moderator
  • Hey all,

    I'm most certain that this question has been one of the most popular and is still evasive.

    It all stems down to an error I receive while trying to RDP from outside my workplace to the TS Gateway. I have the latest RDP on my client, and as far as I know all the correct Roles and configurations on the TS Server.

    Yes, all the TS services are running on my TS Server. At this time our company does not have any licensing CA, and really we don't have a need... or do we now...

    I referenced the above instructions and the step by step guides, TS Gateway & TS License, I emailed the exported cert(.pfx) to my client (I am unaware of how else I can export if I dont have a CA Server) and from there I followed the steps on importing the key/cert to the trusted auth cert tree.

    The error I get when using RDP:
    THIS COMPUTER CAN'T CONNECT TO THE REMOTE COMPUTER BECAUSE THE TERMINAL SERVICES GATEWAY SERVER ADDRESS REQUESTED AND THE CERTIFICATE SUBJECT NAME DO NOT MATCH.


    Here is a report that I generated from the TS License service:
    TS CAL USAGE REPORT
    TS LICENSE SERVER:, "<Servername>" -Omitted by me
    TS CAL TYPE:, "PER USER"
    REPORT DATE:,"<today>" -No relevance
    REPORT SCOPE:, "ALL TRUSTED DOMAINS"
    INSTALLED TS CALS:,"0"
    TS CALS IN USE:,"0"
    TS CAL AVAILABLE:,"NONE"


    I'm currently able to RDP to the server configuring the settings/roles so I know I can establish a connection.

    If I can provide any more settings to help shed light. I don't know if my problem is caused by a needle in a hay stack so what ever I can do to narrow down this problem I will gladly post in response.

    Thanks for reading! and for the feedback!
    -Steve
    Saturday, November 3, 2007 12:56 AM
  •  Alex Balcanqual - MSFT wrote:

    1) issue a cert that matches the externally addressable FQDN of the gateway.

    2) ensure the issuing authorities cert is exported to the client (this is the step most people get wrong, they export the gateway certificate by mistake) this MUST be imported into the trusted root store of the client machine (use the MMC snap in to do this). If the cert goes into the wrong store (usually machine personal or user personal) drag and drop it from that store into the machine trusted root authorities store.



    What do you mean, externally addressable FQDN?  So if the domain is: BigFirm.biz, and the server/comp name is: TermServer, then the external FQDN would be just TermServer.BigFirm.biz?

    What other Cert should I be exporting if not the one I created inside the TS Gateway Manager?


    Thanks,
    Steve
    Monday, November 5, 2007 2:41 AM
  •  

    What do you mean, externally addressable FQDN?  So if the domain is: BigFirm.biz, and the server/comp name is: TermServer, then the external FQDN would be just TermServer.BigFirm.biz?

    <Vikash> : Yes

     

    What other Cert should I be exporting if not the one I created inside the TS Gateway Manager?

    <Vikash>: You have to export the root CA cert to the trusted root store of your client computer.

    Monday, November 5, 2007 4:59 AM
    Moderator
  • Vikash,

    So, I do need a CA Server Service?  Then purchase Licensing?


    Thanks,
    Steve
    Monday, November 5, 2007 12:34 PM
  • At work today I am successful at connecting to the TS Gateway.  In RDP options under advanced/settings, I replaced the external TS Gateway address with the FQDN.
    Monday, November 5, 2007 1:50 PM
  • Make sure on the advanced tab you put the complete name of your ts gateway server for example TS_gateway.domain.com and then the server name that you are trying to connect to must be on your resource allocation list.  So it the name is testserver.  In your RDP just type testserver(this is assuming you have called your server by name in the resource list if not just use ip address.  This is another important step that through me for a loup when it asks you for username and password make sure you put domain/username both times it asks you this is very important as well.

    Monday, November 5, 2007 2:16 PM
  • Thanks Eric, but I still have that issue connecting... TS gives me that Certificate miss-match error when connecting from an external source.  

    Aside from TS not working externally, I am able to remote into the server itself to modify anything, so I know the NAT is working, 3389 and 443 ports.

    Internally it works fine.  So I know the TS RAP is accurate, and the TS CAP might be working... but that's hard to tell because I'm connecting from a domain computer to the TS Gateway and that is forwarding me to another domain computer.  The only difference when I try connected from the external client is I connect using the IP address instead of the "TS_gateway.domain.com" FQDN.

    My TS CAP config looks like:

    If the user is a member of any of the following user groups:
    BUILTIN\Administrators, DOMAIN_NAME\Domain Admins, DOMAIN_NAME\Vista Users
    and the client computer is a member of any of the following computer groups:
    DOMAIN_NAME\Domain Computers
    and uses the following supported Windows authentication methods:
    Password
    then allow the user to connect to this TS Gateway server and disable device redirection for the following client devices:
    Not applicable (device redirection is allowed for all client devices) 


    Could this be my problem?  I'm only allowing computers that are on the domain to connect to the TS Server?

    I am going to research the "resource allocation list", I am unfamiliar with this... but if I can get away with just using an IP address instead of the FQDN (when connecting from an external client) then it should work?

    Thanks for the replies and the feedback!  

    -Steve


    Monday, November 5, 2007 3:33 PM
  • your certificate error, lets see i had that issue as well, I think what ended up solving the issue was to make sure that I placed the cert in the proper spot.

     

    you actually have to but the cert in two spots

    in the trusted root certification authorities as well as let windows choose where to place it. 

     

     

    try that.

    Monday, November 5, 2007 10:04 PM
  • Eric,

    My outcome wasn't as lucky as yours.  I still can't to the root of the problem.


    I do have another question... for those of you that have TS Gateway running externally successfully.  Do you have a CA running? 

    Thnx
    Tuesday, November 6, 2007 3:08 AM
  •  

    My problem was I created a self signed certificate within the TS Gateway which was named after the FQDN (example: TSGATEWAYcomputer.mydomain.com.cer)

     

    I could connect through the TS Gateway from within our domain but externally I couldnt.  Reason why I couldn't connect to the TS Gateway externally using the FQDN was because we aren't providing any external DNS IP Resolution, the Cert did NOT match the server I was trying to connect to.

     

    Originally we created a few firewall rules which allowed external users to connect to the TS Gateway regularly (RDP straight to the TS Gateway machine), the IP address didn't match the name of the certificate TSGATEWAYcomputer.mydomain.com.cer.  So I had to create a new Cert naming it the external IP address for the TS Gateway, now we have a match!  OR go into the hosts file and create a pointer using the original cert...  Which ever is easier for the test clients to handle...

     

    I hope this helps anyone else that was or is having the same problem and sheds some light on what I could do to make this better.

     

    Thanks for all the help,

    Steve

    Tuesday, November 27, 2007 4:40 PM
  • Hello,

    I can connect through TSGateway properly with a self-signed certificate by TSGateway.
    My problem is I can't import my own sefl-signed certificate I generate manually, into TSGateway. I'm able to générate this one, to import it in certificate store, but TSGateway manager does not see it... :(
    I followed explanations here : http://technet.microsoft.com/en-us/library/cc725949.aspx

    And when I compared the self-signed certificate generated by TSGateway with mine, they are exactly the same.
    I really do not understand...

    Thnaks for your help ;)
    • Edited by jorémi Wednesday, August 27, 2008 8:17 AM mistake
    Wednesday, August 27, 2008 8:16 AM
  • did you find a solution for this?  I would appreciate knowing as I'm in the same situation

    thanks

    Thursday, June 28, 2012 4:12 PM
  • I realize this is an old thread, but I need some help.  I've been working on this for several days, getting the same error as above 'your computer can't connect to the remote computer because the remote desktop gateway server address requested and the certificate subject name do not match..'

    I have three servers, a DC, TS Gateway server and a TS Server.  I'm running server 2008 R1 sp1 on all servers.  The TS gateway works fine internally.  I'm using a wildcard certificate from Go Daddy (tried self-signed, was no go).  The gateway server shows that ssl is mapped as *.domain.com.  Client machine settings as follows:

    General Tab --> computer: den11  (terminal server)

    Advanced Tab --> Use these RD Gateway Server Settings --> Server name: mail.domain.com

    doing this does not even reach the gateway server.  If I replace the mail.domain.com with the external physical IP (ie: server name: 8.8.8.8), it will generate the certificate error.  I've verifed that there no DNS problems, if I RDP direct to the terminal server without going through the gateway using mail.domain.com it works fine.  I've read through the microsoft article above (http://www.microsoft.com/downloads/details.aspx?familyid=518d870c-fa3e-4f6a-97f5-acaf31de6dce&displaylang=en) and have tried everything on this tread, any help will be greatly appreciated.

    thanks in advance



    • Edited by Shaka_Z Tuesday, July 10, 2012 5:17 PM
    Tuesday, July 10, 2012 5:13 PM
  • I'm also curious about using a wildcard certificate.  Has anyone been able to get it to work with RD Gateway?
    Thursday, September 27, 2012 12:02 AM
  • This is very useful. But unfortunately many of the links are 'broken'.

    It would have served me well if I could get all material in one place. I am trying to do the same thing at my place & facing many issues. Most of the material is for Ws2008 whereas I am working on WS2012. There are slight differences.

    From :

    shekhar-nsk

    Wednesday, June 12, 2013 8:02 AM
  •  

      OR go into the hosts file and create a pointer using the original cert... 

    This worked for me!

    I hope there is a more detailed, step-by-step instructions on how to create a new cert and naming it with the external IP address. I tried using SelfSSL and used my external IP address as the CN but after that, I don't know where to find the certificate to export. xD

    But since I don't know how, I simply modified the hosts file to have my external IP point to the remote.domain.com, then connect to RWW using the FQDN instead of external IP, and no more certificate mismatch error.

    Monday, September 8, 2014 7:55 AM