0

I was recently informed on SF that using a self-signed certificate for RDP over a public interface is not recommended. In this particular scenario, I'd like to understand more about why.

The situation is this: I RDP into a network by port-forwarding to independent machines on the LAN through a static IP. For example:

External 100.110.120.130:10001 forward to 192.168.1.101:3389
External 100.110.120.130:10002 forward to 192.168.1.102:3389
And so on.

Each machine I need to RDP into (each RDP host) has a self-signed private key, and my RDP client (only this single machine) has the public certificates. The certificates are in the Trusted Root CA store on each machine. The subject CN of the certificate is the static IP 100.110.120.130.

If I configure IPSec on each LAN machine to require inbound/outbound ident/auth/encryption with this and only this certificate on TCP:3389 and UDP:3389, and I'm the only guy with the public keys, can you help me understand the risks in this scenario?

Thanks in advance!

khargoosh
  • 157
  • 1
  • 8
  • The universal problem with self-signed certificates is that although they provide encryption they do not guarantee the identity of the remote server and services you're connecting to. You seem to mitigate that problem by using IPSec for mutual authentication at the TCP/IP level rather than a specific service. – HBruijn May 06 '15 at 04:46
  • Thanks @HBruijn. Presumably this is also mitigated through the fact that I installed the private key on the remote machine/server myself, and didn't install it anywhere else, and then connect to the machine via a static IP. – khargoosh May 06 '15 at 05:01

0 Answers0