Remote Desktop Connection (RDP) - Certificate Warnings

[BrandonWilson]

First published on TechNet on Dec 18, 2017

Hello everyone!  Tim Beasley, Platforms PFE here again from the gorgeous state of Missouri.  Here in the fall, in the Ozark Mountains area the colors of the trees are just amazing!  But hey, I’m sure wherever you are it’s nice there too.   Quick shout out to my buds SR PFE Don Geddes (RDGURU), and PFE Jacob Lavender who provided some additional insight on this article!

I am writing this blog post to shed some light on the question of “How come we keep getting prompted warning messages about certificates when we connect to machines via RDP?”  A couple of examples you might see when running the Remote Desktop Connection Client (mstsc.exe)…

If you’ve come across this in your environment, don’t fret…as it’s a good security practice to have secure RDP sessions.  There’s also a lot of misguiding information out there on the internet…  Being a PKI guy myself, I thought I’d chime in a bit to help the community. 

The answer to the question?  It depends.

Okay I’m done. 

HA!  If only it was that easy!  You people reading this right now wouldn’t be here if it were that easy, right?

To get started, I’m going to break this topic up into several parts.  I’m also going to assume that whoever is reading this knows a bit of PKI terminology.    

Unless there are security requirements that they must meet, most organizations don’t deploy certificates for systems where they are simply enabling RDP to allow remote connections for administration, or to a client OS like Windows 10.  Kerberos plays a huge role in server authentication so feel free to take advantage of it.  The Kerberos authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.  This is the underlying authentication that takes place on a domain without the requirement of certificates.

However, to enable a solution where the user can connect to the apps or desktops that you have published for them from ANY device and from ANYWHERE, then you eventually need to deploy certificates. 

Let’s be clear on one thing:  The warning messages / pop-ups that end users see connecting via RDP are a GOOD THING.  Microsoft wants you to be warned if there’s a potential risk of a compromise.  Sure, it can be perceived as a hassle sometimes, but dog gone it…don’t just click through it without reading what it’s trying to tell you in the first place!  Why not you ask?   Well for one thing, using sniffing tools attackers can successfully extrapolate every single key stroke you type in to an RDP session, including login credentials.  And given that, often customers are typing in domain admin credentials…which means you could have just given an attacker using a Man-in-the-Middle (MTM) attack the keys to the kingdom.  Granted, current versions of the Remote Desktop Client combined with TLS makes those types of attacks much more difficult, but there are still risks to be wary of.

I’m going to go through a few scenarios where the warning messages can be displayed, and then how you can remediate them THE SUPPORTED WAY.   I can’t tell you how many times we’ve seen customers manually change registry settings or other hacks to avoid the warning prompts.  However, what should be done is making sure the remote computers are properly authorized in the first place. 

DO NOT JUST HACK THE REGISTRY TO PREVENT WARNING PROMPTS FROM OCCURRING.  

Read the following sections, or pick which one applies for your situation:

• Scenario 1: Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experien...
• Scenario 2: Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADC...
• Scenario 3: Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experien...

Scenario 1:  Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

I’m going to begin this by saying that I’m only including this scenario because I’ve come across it in the past.  We HIGHLY recommend you have an internal PKI/ADCS deployed in your environment.  Although technically achievable, using self-signed certificates is normally NOT a good thing as it can lead to a never-ending scenario of having to deploy self-signed certs throughout a domain.  Talk about a management overhead nightmare!  Additionally, security risk to your environment is elevated…especially in public sector or government environments.  Needless to say, any security professional would have a field day with this practice an ANY environment.  IT life is much better when you have ADCS or some other PKI solution deployed in an organization.  

A fellow colleague of mine, Jacob Lavender(PFE), wrote a great article on how to remove self-signed RDP certificates…so if you’re wanting the details on how you can accomplish this, check out this link!

Jacob has also written a couple of awesome guides that will come in handy when avoiding this scenario.  The first one is a guide on how to build out an Active Directory Certificate Services (ADCS) lab, and the second link is for building out an RDS Farm in a lab.  Both of course feature the amazing new Windows Server 2016, and they are spot on to help you avoid this first scenario.  Just remember they are guides for LAB environments.

                ADCS - https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1

                RDS Farm - https://gallery.technet.microsoft.com/Windows-Server-2016-Remote-ffc383fe

Off my soapbox now…back to the topic at hand:

More than likely, you’ve decided to RDP to a machine via IP address.  I don’t know how many users are out there that believe that this method is correct.  Sure, it works…but guess what?  You will always get the warning because you are trying to connect using IP address instead of a name, and a certificate can't be used to authenticate an IP address.  Neither can Kerberos for that matter.  So, RDP asks you to make sure you want to connect since it can't verify that this is really the machine you want to connect to.  Main security reason: Someone could have hijacked it. (This is very easily done with environments that don’t use secure DNS btw…)  

Take a quick second to smack yourself for doing this, and make a mental note to establish RDP sessions using machine names going forward…go on, I’ll wait.  :smiling_face_with_smiling_eyes:  If by simply changing HOW you connect via RDP to machines (names vs IP address) fixes your problem…congrats!  You can stop reading now.  And in case you’re wondering, yes…that’s a supported solution.  *stifles laughter*

However, if RDP using names still produces warning messages then let’s continue.  You’ve launched the RDP client (mstsc.exe) and typed in the name of a machine…hit connect…and pops up a warning regarding a certificate problem.  At this point, typically this is due to the self-signed certificate each server generates for secure RDP connections isn’t trusted by the clients.   Think of a Root CA Certificate and the chain of trust.  Your clients want to use/trust certificates that a CA issues, but they must trust the certificate authority that the certificates come from, right?   RDP is doing the same thing.  The client machine you’re trying to establish the RDP session from doesn’t have the remote machine’s self-signed certificate in the local Trusted Root CA certificate store.  So how do we remedy that? 

Solution for this scenario – Export the remote machine’s certificate (no private key needed) and create a GPO that disperses the self-signed certificate from the remote machine to the local machine.   Import remote machine’s certificate into a new GPO at Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities. 

This will install the machine’s certificate accordingly on the local machine, so the next time you RDP using the remote machine’s name, the warning vanishes.  One little caveat though:  Certificate SAN names for CNAME DNS entries.  If you use CNAME (alias) DNS records in your environment, DO NOT try and connect to a machine using the CNAME entry unless that CNAME exists on the certificate.  The name you’re trying to connect to must exist on the certificate!  Otherwise you’ll get warnings despite the fact the cert is deployed in the local Trusted Root CA store.  Just because it’s trusted doesn’t guarantee warnings are forever gone.  You still must connect using the correct machine names.  

Notice I didn’t say to make any registry changes or click the little “Don’t ask me again for connections to this computer” option?  The idea is to get rid of the warning message the right way…heh.

Scenario 2:  Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

Okay this scenario is a little like the previous one, except for a few things.  Devil’s in the details! 

First, your domain-joined client should already have a valid chain of trust if ADCS is deployed…so that can’t be the root cause.  But perhaps it’s not a domain-joined client…in that case get the appropriate certificate(s) installed on your local machine to have a valid chain of trust to eliminate that possibility.  Moving on and re-referencing the info in Part 1, quit trying to RDP to an IP address, and make sure you’re connecting to a machine that has a certificate that contains the name you’re trying to establish an RDP session into.  I don’t believe I need to harp on that one any more...

Normally when deploying ADCS, certificate autoenrollment is configured as a good practice.  In this instance, all users and machines can be configured to automatically enroll for a certificate, barring a published template’s permissions are set correctly.  But RDS is a bit different since it can use certificates that not all machines have.  For instance, just because a machine with autoenrollment enabled acquires a computer certificate from an ADCS issuing CA, doesn’t mean RDS will use it automatically.  Remember, by default the local Remote Desktop Protocol will use the self-signed certificate…not one issued by an internal CA…even if it contains all the right information.  If you want to use a certificate other than the default self-signed certificate that RDP creates, you must configure the RDP listener to use the custom certificate…just installing the cert isn’t enough.  If needed, refer to this article for additional info on configuring the RDP listener for WS2012 /2012R2.  Basically, the right certificate with appropriate corresponding GPO settings for RDS to utilize…and that should solve the warning messages.  How do we do that?

Keep in mind the requirements of certificates that RDS uses:

• The certificate is installed in the local computer’s “Personal” certificate store. (not user)
• 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). You can also use certificates with no Enhanced Key Usage extension.

Now that you have the certificate requirements, you’ll want to create a custom certificate template with the above EKU settings (or none…but I’ve always used Server Auth or RDA).  It’s always best to use a custom certificate template, and not the default ones.  But, I’m not going to completely go off on a PKI best practices rant here…that’s for another day.  (There’s several articles that walk you through this process if you haven’t done so already - here and here).  

Once the template’s created and scoped appropriately via permissions (autoenrollment or whatever) then it’s time for the machine to request the certificate.  Remember, certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that a user is connecting to!  And in this scenario where the RDS Roles aren’t deployed, then the subject name will typically be the machine’s name…configure the certificate template to pull the subject name from AD.   Manual enrollment is a bit time consuming, so I prefer autoenrollment functionality here.

What about computers that don’t have RDS enabled, will they get those certificates too?  Answer:  If autoenrollment is configured and the template is configured to auto-enroll “domain computers” then, Yes.  To mitigate the CA from handing out a ton of certs from multiple templates, just scope the template permissions to a security group that contains the machine(s) you want enrollment from.  I always recommend configure certificate templates use specific security groups.  Where certificates are deployed is all dependent upon what your environment requires.  Just take the time to plan / lab things out before deploying to production…

Next, we configure Group Policy.  This is to ensure that ONLY certificates created by using your custom template will be considered when a certificate to authenticate the RD Session Host Server (or machine) is automatically selected.  Translation: only the cert that came from your custom template will be used when someone connects via RDP to a machine…not the self-signed certificate. 

Create a new GPO at the domain level (or OU...and don’t use the Default Domain Policy…bad practice), then edit it.  Navigate to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Session Host -> Security.  The option you want to set is “Server Authentication certificate template.”  Simply type in the name of your custom certificate template, and close the policy to save it.   As soon as this policy is propagated to the respective domain computers (or forced via gpupdate.exe), every machine the GPO is scoped to that allows Remote Desktop Connections will use it to authenticate RDP connections. 

Here’s an example:  In my lab, a custom certificate with the Remote Desktop Authentication EKU was installed via autoenrollment.  I then created a GPO called “RDP Certificate” and linked it at the domain level.  I updated group policy on a member server, and tested it.

Proof:  In my lab, I got a warning message since I tried to RDP to an IP .   Image2 shows the OID for the custom EKU of Remote Desktop Authentication.  

Of course, as soon as I try to connect using the correct machine name, it connected right up as expected.  Warning went POOF!

Another way of achieving this result, and forcing machines to use a specific certificate for RDP…is via a simple WMIC command from an elevated prompt, or you can use PowerShell.  The catch is that you must do it from the individual machine.  You will need the thumbprint of the certificate you wish RDP to use, and the cert itself must exist in the machine’s personal store with the appropriate EKU.

CMD:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

PowerShell:

$path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path

Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="THUMBPRINT"}

Quick, easy, and efficient…and unless you script it out to hit all machines involved, you’ll only impact one at a time instead of using a scoped GPO.

Scenario 3:  Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experiencing certificate warning prompts when establishing RDP connections.

Now we get to the meaty part (as if I haven’t written enough already).  Unlike the above 2 scenarios, you don’t really need special GPO settings to deploy certificates, force RDS to use specific certs, etc.  The roles themselves handle all that.

Let’s say Remote Desktop Services has been fully deployed in your environment.  It can be 2008 R2 RDS, or 2012 / 2012 R2 RDS.  Doesn’t matter…or does it?  Kristin Griffin wrote an excellent TechNet Article detailing how to use certificates and more importantly, why for every RDS role service.  Her article details RDS certificates for Server 2008 R2, GPO settings, etc.  When it comes to WS2012 and WS2012R2 however, it gets easier and a bit less complicated.  Just remember the principals are the same.  Again, we use certificates to maximize security pertaining to Remote Desktop Connections and RDS. 

By default, RD Session Host sessions use native RDP encryption. However, RDP does not provide authentication to verify the identity of an RD Session Host server. You can enhance the security of RD Session Host sessions by using Secure Sockets Layer (SSL) Transport Layer Security (TLS 1.0) for server authentication and to encrypt RD Session Host communications. The RD Session Host server and the client computer must be correctly configured for TLS to provide enhanced security.  (https://technet.microsoft.com/en-us/library/ff458357.aspx)

First thing to check if warnings are occurring, is (yep, you guessed it) …are users connecting to the right name? 

Next, check the certificate(s) that are being used to ensure they contain the proper and accurate information.  Referring to the methods mentioned in the following information is from this TechNet Article:

“In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session.  

In Windows 2012 / 2012R2, you connect to the connection broker, and it then routes you to the collection by using the collection name.

The certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that the user is connecting to.  For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to.   If you have users connecting externally, this needs to be an external name (it 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, the subject name needs to match the servers in the collection.”

Go and read that article thoroughly.  It talks about proper SAN names to include for external and internal naming for the 2012 / 2012 R2 RDS server roles.  Only the RD Web Access and RD Gateway roles should ever be exposed to the Internet, which means obtaining a certificate for those roles from a Public CA.  

Now that you have created your certificates and understand their contents, you need to configure the Remote Desktop Server roles to use those certificates.  This is the cool part!  For 2012 / 2012R2:

1. On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.
2. Click Tasks > Edit Deployment Properties.
3. In the Configure the deployment window, click Certificates.
4. Click Select existing certificates, and then browse to the location where you have a saved certificate (generally it’s a .pfx file).
5. Import the certificate.

You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (for example: *.CONTOSO.com) and binding it to all roles.  Or you will use multiple certs if you have both internal and external requirements.

Note: even if you have multiple servers in the deployment, Server Manager will import the certificate to all servers, place the certificate in the trusted root for each server, and then bind the certificate to the respective roles.  See!  Told you it was cool!  You don’t have to manually do anything to each individual server in the deployment!  You can of course, but typically not mandatory. 

PRO TIP:  For most scenarios where the client is not domain-joined but connecting via RDP to a machine that IS domain joined you should probably be using an RD Gateway…since in those scenarios the client is coming in externally anyways.

 

Conclusion:

To recap…DON’T try to establish an RDP connection using an IP address.  DO use the correct naming.   DO use an internal PKI and/or GPOs.  DO use custom templates with proper EKUs.  DO use RDS.  

1. You don't have an internal PKI, then use the self-signed certs...and always connect via server names (assuming the DNS suffix on NIC is good) or FQDN. The other takeaway is just have an internal PKI...
2. If you do have an internal PKI, then replace the self-signed certs using GPO and custom certs for the RDS service to use...and connect using server names or FQDN.
3. DON’T connect via IP (did I mention that before?)

And for all our sanity, do NOT mess with the security level and encryption level settings!  The default settings are the most secure.  Just leave them alone and keep it simple.

Thank you for taking the time to read through all this information.  I tried to think of all the scenarios I personally have come across in my experiences throughout the past 25 years, and I hope I didn’t miss any.  If I did, please feel free to ask!  Happy RDP’ing everyone!

Tim Beasley, Microsoft PFE – Platforms.

[SamChoIT]

Can I get your advice???

I am getting that Publisher Pop-up Window msg...

with *.domain.local

I had a self-created cert from the domain with sub.domain.local and SSO was working perfectly fine without any issue...

and we were ready to publish the website address to outside so users can use it from their home.

but now the website is secure and users can log in without any issue and all that but... they get that publisher msg every time they launch their apps...

Am I missing something? or it can not be down with wildcard?

I did use the right Thumbprint...

do external users need wildcard cert installed on their home machine as well?

Any advice will help. 

Thank you in advance

[Tim_Beasley]

Hi Sam, sorry for the delayed response!

If I'm reading this correctly, you have a wildcard certificate installed on servers people are trying to RDP to.  But when they connect in via the internet, they are getting prompted.  

Wildcards for remote applications is fine to use within the configurations of the RDS environment.  But if the end users are constantly being prompted, then it sounds like those users don't trust the chain that wildcard certificate came from.  I've seen this happen when remote devices are things like BYOD and they simply need to trust the CA chain in order for it to work properly.  Meaning, they'll need to have the Root CA cert and any issuing CA cert installed locally.  Then they can avoid the prompt. 

[NikkiAIT]

We also use a wildcard cert for our environment (Win 2016 Server RDS).  We have a GW, CB, and 3 SH servers.  The DNS A Record we use I'm assuming is our farm name (one name pointed to all the SH's IP addresses).

So when using MSTSC.EXE on the outside, we get prompted about the certificate.  The obvious problem is that it's saying we're logging into "ext-gwname.domain.com" and "int-shname.domain.com".  And because of this, it's giving a unknown computer as the cert being presented is an internal cert, not the public cert and DNS we are using.

There's no problem when connecting via RD Web Access.  However, this is a problem because we have terminal clients connecting (so they act more like a Windows PC using MSTSC.EXE).  Troubleshooting why our external terminal clients aren't working (Axel terminals), we tried using a Windows PC via MSTSC.EXE to connect and that's how I found out the weird "unknown computer" warnings, where the SH server is presenting it's internal name and internal cert rather than using the farm name and using our wildcard cert (that's publicly signed).

[Cody Kirkland]

@NikkiAIT are you still having issues with this? I see it's been a few months. In your deployment properties, are all the certificates showing as "trusted"? If the session hosts are handing out their self-signed certs rather than the wildcard cert in your deployment properties, there's a problem in your configuration somewhere. On which server(s) are your Web Access roles installed? I assume your Session Hosts, since you stated the web access is presenting the self-signed cert for the Session Hosts rather than your wildcard. 

[Ricoli610]

@Tim_Beasley

Remote Desktop Services has not been deployed but we do have an internal PKI.

When configuring a new template with the Remote Desktop Authentication EKU, is it necessary to tick the option to Publish to Active Directory?

I have specified the template name in group policy via Server Authentication certificate template.  Certificate auto-enrollment is not enabled.  The server keeps enrolling for a new RDP certificate each time it reboots and on running gpupdate /force.  The server and the CA are running Server 2012 R2.  The certificate template display name and name are both the same.

Should the server automatically renew the certificate once it enters the renewal period specified on the template?

Thanks very much.

[Tim_Beasley]

Heyaz Ricoli!

"Publish to AD" option in a template does just that, it makes a copy of the cert and stores in the object attributes.  Depending on the template settings, you could create duplicates over and over again inside AD.  This is particularly prevalent with the default user template.  I digress...

In regards to the renewal during reboot scenario, this would happen if you have a cert lifetime that's extremely short (more likely your case) or have a renewal period that spans the GPO refresh cycle.   Double check the template settings and certificate lifetimes. 

[Ricoli610]

@Tim_Beasley 

That's great, thanks very much.

[willahlborn]

I was hoping for some input on our deployment...

we are not using internal PKI for the RDS farm.  Our internal domain name suffix is .com, so for example, our AD forest is "acme.com".  We have purchased a wildcard certificate for *.acme.com from a public CA which we should be able to use for machines on our internal domain.  I have applied this wildcard certificate to the Deployment Properties of our RDS farm on all four role services: RD Connection Broker: enable SSO, RD Connection Broker: Publishing, RD Web Access, and RD Gateway.  This set the Certificate Level as "trusted" with a status as "ok" for all four role services.  Now, when I visit our deployment from an external host (https://rdp.acme.com/rdweb) and RDP to one of my host collections, I still receive a certificate error from the broker--it shows that "broker.acme.com" is still using a self-signed certificate.  How do I fix this?

Furthermore, I have configured the deployment to use "rdp.acme.com" as the RD Gateway server name, yet when I log in to RDWeb and click on a collection, the RDP session lists the "remote computer" as "broker.acme.com" (correct) and the "gateway server" as "gateway.acme.com" (incorrect; this should be rdp.acme.com).  I've been unable to correct this setting as well.  Any advice? 

[Tim_Beasley]

Hi Will!  What you're inquiring about is a bit different than what this post was geared to address.  You're wanting to know more about an actual RDS deployment vs. ridding yourself from the "annoying" cert warning popup.  But that's ok, I can point you in the right direction to start.   Begin with this article here -https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn...

Keep in mind on how RDS works.  Hitting the RDWeb server and opening a collection will take you to the gateway to process any conditional policies, then pass it to the broker for directing to the proper session host.  SAN entries are used, not the CN of the certificate.

From a security / PKI perspective wildcard certs aren't generally recommended.  You add more risk that way.  I'd focus on leveraging a SAN certificate that contains all the FQDNs of the RDS Servers.   The behavior you're seeing has to do with how RDS roles process the traffic/certs.  Technically speaking, your wildcard certificate should be fine as long as the *.acme.com entry is in the SAN field...AND...the internal FQDNs of servers are also acme.com.  Choose the option that fits your business needs...what does your security team say?  Are they willing to accept the additional risk?  If so, make sure the wildcard SAN is correct.

If you continue to have issues in this particular situation, I advise you open a case with CSS. 

[U2Pas]

Hi Tim

thanks for detailed explanations.
i.e. I have a server in a remote computer center I am accessing by RDP with SSL cert over internet(client non-domain joined).

The Let's Encrypt cert get's automatically renewed about all 2 months on the server, is there a way to automatically update it on the connecting client too or do I always have to make a export and send it to customer again ?

thank you

Urs

[Tim_Beasley]

Hi Urs!

By using a 3rd party certificate, you're limited to a manual export/import process.  I bet you could script it via PowerShell to speed things up a bit, but still more-so a manual thing.

[Grumpy_Old_Man]

@Tim_Beasley 

Not sure what you mean by manual process, I have a "few" RDS deployments fully automated with LetsEncrypt certificates

get the certificate, mangle the certificate into the form that RDS wants, deploy the certificate during the monthly maintenance window...

https://docs.microsoft.com/en-us/powershell/module/remotedesktop/set-rdcertificate?view=win10-ps

[Tim_Beasley]

@Grumpy_Old_Man 

Manual = no built in automation, hence why I also mentioned scripting via PowerShell.  Thanks for providing the link for others to reference. 

[Chris Smith]

It kind of bothers me that I get a certificate warning when I RDP into my non-domain-bound offline root CA.  (It's a VM, so it is either RDP or the VMWare console ... Microsoft Remote Desktop behaves better, so ....)  If I wanted to fix this, could I issue a (second) certificate (with the hostname/FQDN of the machine) into the Computer store?  The root cert is in there .... that won't cause a problem, will it? 

[Tim_Beasley]

@Chris Smith 

I'm very tempted to go off on PKI hardening / best practices right now, but that is not on topic.  (I strongly urge you to do research though!)  To answer your specific question...any non-domain joined windows device will always use a self-signed certificate unless explicitly configured.  Additionally non-domain joined machines won't ever receive GPOs...

In your case, you're talking about the Machine's Personal store...which is different from the RDP store.  Swap the cert in the RDP store and you might also need to visit this article: https://support.microsoft.com/en-us/help/3042780/remote-desktop-listener-certificate-configurations-... 

Thanks!

[WintelGeek]

I very much appreciate this post and the details and examples are very helpful.

I realize this is perhaps geared more toward Terminal Services, but for Windows systems, I would assert this is not, technically, the proper setup. Microsoft should be enabling the use of the certificate store for the service via GPO. What I mean is that there is (A) a node in the Windows Computer Certificate store for the self-signed certificate which is specific to the "Remote Desktop Services" service on Windows-based OS's which is automatically used for RDP, and (B) there is a certificate store specific to services running on the OS platform, and specifically for the "Remote Desktop Services" service. Furthermore, when you look at the self-signed certificate, it only has the "server authentication" enhancement, not the RDP OID.

Regarding point (A), there appears to be no way to automate a certificate install to that node in the Computer certificate store.

Regarding point (B), there is no strictly GPO-based method of getting a special certificate into the certificate store for the "Remote Desktop Services" service. Auto-enrollment certainly is not supported.

Microsoft has made the needed certificate store parts available but has developed no way to utilize them with Microsoft PKI, auto-enrollment, or GPOs (outside of the Computer certificate store, short of running scripts and using registry keys).

To get rid of the RDP error message for connecting to Windows-based computers where you already have Microsoft PKI (or some other internal PKI), it seems to me that the most effective method of eliminating the warning would be to simply add the RDP OID ("1.3.6.1.4.1.311.54.1.2" for the "Enhanced Key Usage") to an existing device/computer certificate that your PKI is already issuing to computers/devices, if you are already pushing out certificates for computers. No need to push out a new certificate template.

But this, technically, doesn't place an RDP certificate in the correct, more "correct" place. I would think that PKI specialists would want the service to have the certificate rather than the computer account. A technicality, I admit, but Microsoft has had many years to properly develop these PKI pieces. I had to do custom scripting to secure LDAP and it seems that the same mechanism is needed for RDP.

[CromeX]

Hey, thanks for the great article. Honestly is goes a little above my head. I'm a home network and I'm using RDP to log into my desktop through a laptop. 

What are the risks of leaving the Certificate "Unknown". How can I fix it for just a hand full of pc's a home setup not a business setup? 

That would be super helpful. 

[Hillsinc]

This is an excellent article!  Well written and I agree with the logic of "make it work" instead of registry hacks and "don't bother me" checkboxes.

We are experiencing problems recently with Windows 10 ver 20H2 domain PCs on our network.  We have a local CA with relevant certificates being issued.  No problems with RDP to servers (2012R2, 2016, 2019) or domain PCs Windows 10 ver 1909 or 2004.  With the "Allow connections only from computers running Remote Desktop with Network Level Authentication" checked on the 20H2 PCs, we receive this error.

Domain DNS and DHCP is configured properly and name resolution is working fine.  If we uncheck, the "Allow connections..." box, we no longer have that error, but the self-signed cert is being used by RDP, not the one issued by our inhouse CA.  I prefer not to use the registry hack to force the RDP service to use the thumbprint of the proper certificate as that will get messy quickly with 100 workstations.

Has anyone else seen this behavior with Windows 20H2 clients? 

Once again, we do not have this problem with any earlier versions of Windows 10 nor our servers.  Just the 20H2 workstations.  Any assistance or recommendations are most welcome.

Regards,

Todd

[Tim_Beasley]

@CromeX  - Apologies for the delayed response, but you should be fine with the self-signed certificates in a home network.

@Hillsinc  - In your particular case, I personally haven't heard of 20H2 causing funky issues like what you describe.  I hate to punt, but I suggest opening a case with CSS to see if you stumbled across a possible bug.

[mcham_mao]

Thank you

Very nice article. I know I come here after a few years but a good article never goes old.

The dilemma I have here and I am at the point if I should scratch the internal CA and move to a public CA for all our RDP needs.

Withe everyone ringworm remotely and using and/or having a hybrid module were user either use their own personal equipment or provided, over a vpn connection we have it a bit hard time to assist users.

Since we are using a Terminal server farm, I ant the staff just to open remote desktop, type the rds farm collection name and go in with no cert warnings .

To do this, I was thinking to use our regular wildcard certificate that we use to secure the other applications we use with the "hassle" that ow we need to do this every year.

The opposite will be for us to start deploying a CDP site that takes care of the CRL revocation and assist user with the certificate at the initial rdp start and provide guideline how to import the certificate to the personal computer store .

Any suggestions here will be greatly appreciated.

Thanks

[Tim_Beasley]

Sorry for the late reply!  Thank you all for the feedback, much appreciated!

Moving from an internal PKI to a public CA, that really comes down to cost.   If the business can afford it, and just wants to eliminate the management of an internal PKI...go for it.  Or, if they would rather ramp up the IT staff to properly manage PKI for a one-time cost vs. recurring charges from a Public CA, then that works too. 

Related to the use of wildcard certs...from a security standpoint...bad idea.  I would recommend a SAN cert.  From an ease of operation standpoint...makes it easy to deploy.  There's lots of guides online on what is best use case for an RDS deployment.  

[fcolvin]

good morning. I am having an issue similar to this with an exception. we use a proxy server for RDP access to our servers. this is a Privilege access methodology where we log into a web ui and ask for access to a server, proxy server 1 sends us an rdp session (which comes with the untrusted publisher warning). this rdp session has an address of VIPaddress.internal.local:4489 this VIPaddress is not trusted in our organization nor does it have this in the trusted rood certs. how can we stop getting this warning?

[IES_Radu]

Is this thread dead? I need help with RDP in home environment. I need to acces my home computer from my class with RDP and I only want to allow access to remote machines that have a certificate issued by me (yes, I issued a certificate my self, copied on a stick and imported it in the classroom pc). I also configured RDP from GPO to use that specific certificate, but when I tried to access it from a different machine (tested from mobile too), it offered a default generated cert, thus allowing the connection. How can I force it to use the issued certificate and stop it from allowing connection if that certificate is not present on the connecting device? I don't have a server or AD or anything of sorts (for now), it's just a simple desktop with Windows 10 Pro... I'm studying Network and Systems Administration and we work a lot in VMs and I'm tired of having to clone machines back and forth to finish my practices, I want to access the VM at home directly, and since I can only get access and custom ports open by having a public IP (and out of CG-NAT infrastructure), I'm completely open to RDP attacks. I do have separate accounts for the users that I use with RDP but they have access the other drives/partitions and parts of the files of the admin account (since I might need to get something from my Desktop, Documents) and I don't want to mess with user permissions for now. I still think the most secure option in this case will be blocking access if no certificate is present. Thanks in advance!