The operating system my web server runs on is (include version): Windows Server 2019 Standard
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A
We all know the common cert warning we get using Windows Remote Desktop if we aren't using a recognized certificate authority. So I thought I would attempt to fix it (for the heck of it). I'm more than confused and have found several sites that offer information but little that I can make sense of.
So first question. I have a certificate for my domain can this certificate be used for more than one purpose and particularly can I use it for my access to my server from my computer using RD?
If so that might be the end of the questions but... If I do need a specific one is there a name for this type and do I have to name my server anything special or what? And does Let's Encrypt supply such a cert?
The instructions I've found for installation seem lengthy but I figure if they are correct I can follow them.
Yes. RDP certs require "Server Authentication" which all LE certs provide.
It shouldn't be too complicated... Maybe those instructions are outdated.
I would first recommend that you get a good ACME client for Windows.
Preferably one that has already figured out how to properly install an LE cert for RDP use:
Sorry to bother you but... I added my www.leylan.com cert to the Remote Desktop / Certificates collection (I removed the server named one) and every time I try to remote a server name based cert that is automatically generated is presented. I look in the that folder and it has been restored there.
I do not have all this RD Services and such installed just turned on the ability to remote into the server. Could this be why I'm having issues and is this service free for a single user because everything I could see about it sounded like I had to sign up for some CAL stuff.
I'm pretty sure Certify the Web supports a deployment action that will automatically take care of setting the RDP cert for you. This is the canonical question/answer I usually point people to for DIY stuff though:
It's a common misconception that the cert needs to be in the Remote Desktop certificates store. It will work fine from the Personal store as well just like IIS. But regardless of the store, something still needs to explicitly tell RDP to use that cert via it's thumbprint value. Using WMI is usually the best way because it ensures the cert's private key has the appropriate permissions for RDP to use it. There are registry methods that I've seen people use, but they only work if the permissions are already correct.
Also, don't worry about the self-signed cert in the Remote Desktop store. Windows will regen a new one even if RDP is already configured to use a different cert. You can just ignore it.
Slowly but surely it is making (some) sense. I used your scripts to make the change and CTW has a script that I can add to keep it up-to-date. The current issue is now Cloudflare as the cert name no longer matches and I basically have the same issue once again.
I'm looking into solutions for that OR I might just put up with having to click ignore each time
Interesting. I kind of don't understand why it would make a difference in this particular case. Let me explain that it is "a legitimate certificate for my domain". I can see my certificate and I got to that server thru the IP address.
I'm more than happy to fix it but I'm not paying $100 for a server license or $500 a year for something or another that seemingly doesn't offer any better security. Requiring that these solutions take more than a button push or two from "the average developer" indicates (to me) that something is slightly wrong with the way security currently works.
It is not necessarily my server if I see my own certificate in the warning?
I appreciate all the feedback but it isn't making a lot of sense. I realize there is no IP address on the cert. I can see the cert, I requested the cert, I have two certs actually.
The issue appears to be that Cloudflare is in the mix. I do use my domain name and Cloudflare won't put the RDP attempt thru to my server. So I use the IP address and avoid Cloudflare for this.
I do get on and have been for maybe 10 years. I thought it would be nice to eliminate the warning.
It isn't your job to educate me but if I access my server via the IP address and I see the cert I installed who got in the middle and why couldn't they get in the middle regardless? I'm at a total loss, it is like auto airbags are a great safety feature so someone is offering a way to build your own airbag in 10 steps. If all this security is worthwhile and of course I think it is how can it take anything more than a short questionnaire and a few button pushes?
There are self-parking cars and I just saw a rocket land itself the other day. Why make security harder than it needs to be?
They can't produce a legitimate cert for your domain name.
They CAN produce one that is self-signed and will throw the exact same error you are accepting.
You've put that name behind CloudFlare - and haven't made any consideration for RDP port.
You are likely allowing the entire Internet access to your REAL_IP:RDP_port so CloudFlare isn't even protecting you form RDP attacks.
Yes. Trying to have Cloudflare protect your website and use the same name for RDP won't work without hassles as you've already discovered.
I'll also agree with @rg305 that exposing RDP directly to the Internet is a terrible idea without at least a 3rd party 2FA solution in place. Better to use an entirely different remote protocol though. I'm personally a fan of AnyDesk which includes built-in 2FA.
If you're dead-set on using RDP though, what you can do is create another A record for a different name such as rdp.leylan.com (but maybe something less obvious) pointing to your server's IP that is not protected by Cloudflare (still in Cloudflare DNS, but with the "Proxy status" set to DNS Only). Then you get a separate cert for that name that is only configured for RDP and leave the original cert in IIS for your website.
Cloudflare will give a warning about the RDP record potentially exposing your Origin server IP. But that's kind of the point unless you have an additional public IP you can use on this server.
Thanks everyone. I did record a separate A record and that bypasses Cloudflare. I've successfully remoted into my server without seeing the cert warning. So I have a legitimate certificate that (I think) due to it succeeding now a MITM couldn't reproduce it (the cert).
I'm not dumb I can understand how receiving a text message prior to letting me in or immediately upon letting me in would be very, very helpful. AnyDesk is however $10 a month to yet another private company. If they are ever hacked I'm sure their insurance will kick in and everyone will say "I wonder how that happened". Again I'm not claiming it isn't worth it or anything else but there is always another $10 to cover your phone, your computer, your coffee machine.
Someone with the power needs to build security into the security as part of the protocol or few people are going to do it (my 2 cents anyway).
In any case my problem is solved (4 sites and about one full day of messaging and research) and I sincerely thank you all.
So yes, it's pretty essential to limit who can connect to RDP because the script kiddies will point something at your server and run 100000 password attempts for Administrator. This actually works in many cases.
It's good to at least limit RDP connections to your own IP address (ideally in your VM networking, so you can fix it if your IP address changes), and there are tools to auto-ban IPs if they make multiple failed attempts to RDP. You can also use things like Cloudflare Tunnel (which has a free version) to allow your device access to RDP on that server via a VPN.
For folks looking to get a cert using Certify The Web and use it for basic RDP (as already mentioned here):
On the server where the cert is required, get your certificate using Certify The Web (DNS validation if you can, http validation with port 80 open if you need to), then add a Task for "Deploy to RDP Listener Service (Terminal Services)" which will update the local RDP listener service. You may then also need a service restart task (optionally, as testing that will kick you out of RDP).
There are other Tasks (for RDP gateway services et)c but it gets complicated when you have multi server updates and at the point I recommend your own scripting rather than relying on pre-baked magic, so you know exactly what's happening.
Is there a way that you could use, and require, a cryptographic key to authenticate for RDP, thinking of the Unix analogy where you can require a key for SSH as root instead of permitting password authentication? An advantage of that is that attackers can't guess the cryptographic key, even if they might have guessed a human-created password.
One form is kind of like "can you guess the word sw0rdf!sh?" and the other is kind of like "can you determine p and q such that pĆq = 22225705922532974279531810966285052970973934254867051461760162359199330745370633950994586249384999959879274627825717187177507496572005124440577125559607208248139552291680584278837213785273685889047580324472524446769940393876014682438967237266516139847154247051969234194776144764962733585166030576239756285084466260541909236400960289277361237713306137342629059640000385613201989660622984421772062391851937387418773748951794204808033109535746300814729158311237156456544094062086370049359388561892004856305572744661915241053177382026744845858462633165253741348090962371404537719214511526010451539781041712547320251554813?
I think you can use the MS Remote Desktop Gateway service (specifically designed for brokering remote desktop connections), then require client certificates (so, mTLS), but I don't know for sure (you can certainly require smart cards).
MS RDP is essentially not much more than HTTPS on a non-standard port; As such it can be proxied by any normal web service - which can in turn, require any level of authentication available to it (before passing you to the backend MS RDP system).
You sure you're not thinking of Remote Desktop Gateway, @rg305? The base RDP protocol bears little to no resemblance to HTTP. There are TCP and UDP communication channels happening simultaneously, all sorts of crazy stuff. It doesn't even use TLS encryption by default unless you turn on "Enhanced" security. Actually, I think the TLS mode is now default, but the original default is this homegrown encryption scheme that still ultimately uses a cert, but is not technically TLS if I understand correctly.
The biggest downside to RD Gateway is that it requires purchasing additional licensing beyond the base OS license.
