1

I want to make sure the users connection is as secure as possible. Our RDWeb server has a .local name (for this question it will be called rdweb.contoso.local) and a public name: rdweb.contoso.com

We have a premium ssl from godaddy for the RDWeb website (rdweb.contoso.com). When a user clicks to run remoteapp A it connects to the rdweb server. The connection box to the rdweb server says, "...connecting to rdweb.contoso.local" then asks for the user to login to rdweb.contosto.local. After successful login a window asks the user if he wants to continue to the connection of rdweb.contoso.local because it cannot be verified. If you click on view certificate you can see that for that connection the self-signed certificate I built in IIS is being used. Is this secure? The remote app used from RDWeb is an HR/payroll application that has sensitive employee information.

So, is the self-signed certificate okay for the connection from the RDWeb website to the rdweb server? We have a premium ssl for the rdweb website itself (rdweb.contoso.com)

If that self-signed certificate isn't safe for this situation then how can I make it safe? Purchase an SSL for the .local from godaddy?

we've been using this process for a while and I just happened to think about the safety of the connection. I understand it's encrypted and I do trust the certificate since I know it came from the server. Just wanting some thoughts on it.

Thanks everyone.

OS: server 2008 r2 Windows 7 and 2008 r2 active directory environment The RDWeb users logins into RDWeb from external location to our local network

Improve this question

2 Answers 2

Reset to default
3

The solution here is to make everyone connect to rdweb.contoso.com, and never use the rdweb.contoso.local address. In most cases this will require either split DNS or NAT hairpinning/loopback to work properly.

By using the public name, your godaddy SSL certificate will work properly. No reputable provider will give you a signed ssl cert for any *.local address since there's no way to prove ownership (in fact, you don't own it, but as long as it's only on your LAN it doesn't break anything else if someone else uses it on their LAN).

Using a self signed certificate is bad - particularly because it trains users to completely ignore the warning about the certificate being invalid. That makes it much easier to trick someone into connecting to a different service or hijacking the connection.

Assuming you have your contoso.com DNS at godaddy, and your contoso.local DNS in active directory, you can add contoso.com to your AD DNS servers, with all the records it has at godaddy. But when you get to rdweb, instead of the public IP address, put in the private address.

Or just make your firewall/NAT device allow connections from the LAN to connect via the public address. This is often called NAT hairpinning, loopback, or a few other similar names.

Improve this answer
6
  • Thanks for the answer. I didn't explain the process very well in the question. I apologize. We have a public IP for the RDWeb site. I have an a record i our public dns at godaddy for public FQDN of the rdweb server. Also, in our firewall everything is set for the remote access to rdweb. The rdweb server is public facing. The remote user accesses the rdweb site using the public FQDN of the server: rdweb.contoso.com We have the ssl from godaddy bound to that address. So access to the site is trustworthy and safe. However, when an app from the site is executed that's when the .local happens.
    – Art.Vandelay05
    Mar 14, 2013 at 16:43
  • remote user -> rdweb.contoso.com -> run remote app -> remote app executes using rdweb.contoso.local so user has to trust that self-signed cert
    – Art.Vandelay05
    Mar 14, 2013 at 16:45
  • Then you need to reconfigure remote app to use the contoso.com name instead of contoso.local.
    – Grant
    Mar 14, 2013 at 17:22
  • okay thanks. So just to clarify it's not that self-signed certificates from IIS in server 2008 aren't safe speaking of encryption but they're not safe due to possible deception?
    – Art.Vandelay05
    Mar 14, 2013 at 17:42
  • 1
    Exactly. The encryption does you little good if you cant be sure you are talking to the right person in the first place.
    – Grant
    Mar 14, 2013 at 20:52
0

It's unprofessional to use a self-signed cert for an internet service. The idea is that we trust a certificate from GoDaddy or Digicert more than we trust your self-signed cert. It can be validated by the issuing certificate authority's online validation servers. Your self-signed one cannot. If your server is compromised and someone steals your private key, they can forge a certificate and play man in the middle for your unsuspecting users who have been told to trust your self-signed cert. Yes traffic is still encrypted when using a self-signed cert, but it's more about trust.

Also you've gone and made this hard on yourself by naming your domain *.local.

Improve this answer
2
  • Thanks for the answer. I didn't explain the process very well in the question. I apologize. We have a public IP for the RDWeb site. I have an a record i our public dns at godaddy for public FQDN of the rdweb server. Also, in our firewall everything is set for the remote access to rdweb. The rdweb server is public facing. The remote user accesses the rdweb site using the public FQDN of the server: rdweb.contoso.com We have the ssl from godaddy bound to that address. So access to the site is trustworthy and safe. However, when an app from the site is executed that's when the .local happens
    – Art.Vandelay05
    Mar 14, 2013 at 16:43
  • yeah, i inherited the .local and haven't changed it. :\ I thank you for pointing out that even though the self-signed is encrypted and "safe" in that sense, using it is getting the remote user used to just accepting a self-signed cert which isn't good.
    – Art.Vandelay05
    Mar 14, 2013 at 16:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .