none
Implementing SSL for RDP connection (RDP listener on the RD session host) RRS feed

  • Question

  • Hi,

    We have Win2008 R2 server with RD session host role. It is accessible by RDP from the public Internet under certain globally-visible DNS name in .com domain. Also this server is a member of Active Directory domain (DNS suffix for this domain is internal, non-public-visible, ending with .local ).

    Now we would like to implement SSL certification for this RDP server, so that clients connecting from the outside do not get certificate warning on connect.

    By mean of IIS7, we created a certificate signing request for the external DNS name of the server, and signed it at AlphaSSL as a free/trial certificate valid for 45 days. Then completed certificate signing with AlphaSSL reply, and installed this certificate into IIS7. Now we can access to its external DNS name by https to IIS7 default page, and the browsers say the site is trusted. Certification path starts with GlobalSign, under that is Alpha CA, under that is our cert for this domain.

    Next step, we are trying to install this same certificate in the properties of RDP-Tcp connection of RD Session host, instead of auto-generated cert. which is there by default. On clicking 'Select', it allows to pick the certificate from the list (its EKU attributes are 'Server Authentication (1.3.6.1.5.5.7.3.1) and Client Authentication (1.3.6.1.5.5.7.3.2)') and shows it is active. But then, on connection attempt from RDP client (usual MSTSC included into Windows 7 Prof.), we get a warning that "the certificate is not valid for this usage".

    Then we re-tried, having got free/trial certificate for the same DNS name from Comodo/EssentialSSL (or InstantSSL). Its certification path is a bit longer : USERTrust/ComodoCA/EssentialSSL CA/our one. Its EKU contains : Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), Unknown Key Usage (1.3.6.1.4.1.311.10.3.3) and Unknown Key Usage (2.16.840.1.113730.4.1). We used the same IIS7 dialogs to create/complete certificate request. And yes, this another cert. is too possible to assign to RDP-tcp connection, but it is still not valid for this RDP-tcp usage.

    Now I want to ask experts, what exactly I am doing wrong, what details do I overlook and what have to do in different, correct way, to obtain a certificate usable for RDP and signed by known SSL trust vendor ?

    Is the problem in EKU ? Is it in too long Certification path ? Does IIS7 form a too restricted cert.sign.request ?

    How should I properly form cert.sign.request on my side ? Should I bring up Certificate Services in the domain to get the proper certificate request templates ?
    Should I demand anything specific from my SSL vendor when buying a certificate from them (to make it usabel for RDP) ? Should I sign my Cert.Serv. root at SSL vendor just for this simple purpose ? (I am afraid this is going to cost too much money for us to really afford)

    Thank you in advance for your competent and useful replies .

    Wednesday, February 16, 2011 3:47 PM

Answers

  • Hi,

    The OIDs (1.3.6.1.4.1.311.10.3.3 & 2.16.840.1.113730.4.1) that you said are in the EssentialSSL trial indicate that it is a SGC cert.  It is possible that one or more of the certs in the chain for your AlphaSSL trial cert is an SGC cert as well.  Based on reading the thread that Kristin referred you to this would explain the problem you are seeing from Windows 7 clients.

    I recommend you obtain an SSL certificate that is not an SGC certificate and also does not have any SGC certificates in its chain.  For example, you can purchase a standard non-SGC ssl certificate from godaddy for $12.99/year.  The godaddy certificate has one intermediate certificate in addition to the root.  To get the $12.99 price google for godaddy $12.99 ssl and then click on the link.

    Another alternative is a RapidSSL certificate from www.rapidsslonline.com.  It is as low as $10.99/year and is issued directly from a root certificate (GeoTrust), in other words, no intermediate cert.  They offer a 30-day money back guarantee.  It is not a SGC certificate, and the root is not an SGC certificate. 

    There are other providers that are cheaper or even free  (startssl), however, I have not tested them.

    If you need to secure multiple servers/RDS roles you should consider a wildcard certificate (as low as $99/year), or a UCC/SAN certificate ($60/year).  If all of your RDS servers/roles can be under a single domain then a wildcard is really convenient.  This is because you can add new server names as needed and still use the same certificate for all.  If you have older RD Client versions in your environment then a UCC or wildcard may cause problems.

    -TP

    Monday, February 21, 2011 4:03 AM
    Moderator

All replies

  • I am having the exact same issue, also with a Comodo free 90 day certificate. Have you managed to find anythinig else out yet?
    Friday, February 18, 2011 5:28 PM
  • Hi,

    The client connecting must trust the certificate you are using. If the trial certs are signed by comodo, then make sure the client has the comodo CA cert in their trusted root store.

    also, see if this thread will help you: http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/b6545e0e-8a86-4b44-a118-0489fe76fdd1

    Also, FYI: you say: It is accessible by RDP from the public Internet under certain globally-visible DNS name in .com domain.

    I would not recommend this. It makes your server vulnerable because it is open via port 3389 to the internet. Close this and use RD Gateway to give users secure access to your environment via port 443. (The 2008 R2 RDS Resource Kit walks you thorugh this and there are MS guides too: http://technet.microsoft.com/en-us/library/dd983941(WS.10).aspx)

     


    Hope this helps,

    Kristin L. Griffin

    SUPER BIG fan of the Remote Desktop Virtualization Team!!!) 

    My RDS blog: blog.kristinlgriffin.com

    The new Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit is now available!
    Friday, February 18, 2011 9:03 PM
    Moderator
  • > The client connecting must trust the certificate you are using. If the trial certs are signed by comodo, then make sure the client has the comodo CA cert in their trusted root store.

    Web browser connecting to the site by https says the certificate is trusted. All uplevel certificates in the certification path are in the local Trusted Root cert.store. Should they be in some another specific store ?

    > I would not recommend this. It makes your server vulnerable because it is open via port 3389 to the internet. Close this and use RD Gateway to give users secure access to your environment via port 443.

    Yes I know about RD Gateway and have implemented it as well. But MSTSC still warns about untrusted/self-signed RDP certificate, even after successful https-tunnelled connection. (or about invalid cert.usage when I replace the default/auto-generated cert. with free/trial real SSL one.)

    So the questions still remain unanswered : how to properly form RDP cert. signing request ; and whether it is possible to sign such a request from well-known SSL trust vendor ? (setting aside the much more expensive signing of cert.services root)

    We want to provide direct or gatewayed RDP access to outside (not in AD domain) clients which will not ask them to click through various certificate warnings. They need to be sure from the start that their connection is secured and trusted. It's a pressing business need of my employer. Do we have any hope and any chance to succeed with that ?

    Sunday, February 20, 2011 6:02 PM
  • Hi,

    The OIDs (1.3.6.1.4.1.311.10.3.3 & 2.16.840.1.113730.4.1) that you said are in the EssentialSSL trial indicate that it is a SGC cert.  It is possible that one or more of the certs in the chain for your AlphaSSL trial cert is an SGC cert as well.  Based on reading the thread that Kristin referred you to this would explain the problem you are seeing from Windows 7 clients.

    I recommend you obtain an SSL certificate that is not an SGC certificate and also does not have any SGC certificates in its chain.  For example, you can purchase a standard non-SGC ssl certificate from godaddy for $12.99/year.  The godaddy certificate has one intermediate certificate in addition to the root.  To get the $12.99 price google for godaddy $12.99 ssl and then click on the link.

    Another alternative is a RapidSSL certificate from www.rapidsslonline.com.  It is as low as $10.99/year and is issued directly from a root certificate (GeoTrust), in other words, no intermediate cert.  They offer a 30-day money back guarantee.  It is not a SGC certificate, and the root is not an SGC certificate. 

    There are other providers that are cheaper or even free  (startssl), however, I have not tested them.

    If you need to secure multiple servers/RDS roles you should consider a wildcard certificate (as low as $99/year), or a UCC/SAN certificate ($60/year).  If all of your RDS servers/roles can be under a single domain then a wildcard is really convenient.  This is because you can add new server names as needed and still use the same certificate for all.  If you have older RD Client versions in your environment then a UCC or wildcard may cause problems.

    -TP

    Monday, February 21, 2011 4:03 AM
    Moderator
  • I checked my both certs, and found that AlphaSSL one does have these Microsoft/Netscape SGC OIDs in Alpha CA cert.

    Now I will try to get non-SGC cert. to check your advise. Thank you in advance, I hope this will be helpful.

    Monday, February 21, 2011 6:43 AM
  • Thank you a lot, your advise is completely right !

    I requested free certs from StartSSL and RapidSSL, they both do not contain SGC OIDs anywhere, and both work well as I long wanted !

    Why Microsoft decides to reject this SGC, and why it is kept by well-known SSL vendors, is still a big mystery to me ...

    but anyway now I understand how to bypass it and what SSL vendor to choose for buying real certificates, thanking entirely to your help !

    Monday, February 21, 2011 1:36 PM