Security Certificates

[HCHTech]

This is likely a 'networking 101' question, but it's got me second-guessing myself so I'm asking it anyway.

Where should I be installing an SSL certificate, and can it be more than one place for a given network?

So I have a subdomain name used for more than one purpose at a client's office = remote.smithmfg.com let's say. DNS points this to the public static IP of the office's internet connection. They have a Sonicwall as their edge device, and the standard domain controller and application servers. They don't currently have an RDS gateway.

They use Sonicwall's NetExtender SSL VPN client on their travel laptops to connect to the network and RDP into workstations at the office. I have an SSL certificate for remote.smithmfg.com installed on their Sonicwall to authenticate those SSLVPN connections. Works fine. They also have IP credit card terminals, so we use cc.smithmfg.com to point to a 2nd static (they have a block of 5 available) to use for that purpose. I have a 2nd SSL certificate for cc.smithmfg.com installed on the Sonicwall and all traffic coming to that IP is on a separate VLAN/subnet where their credit card terminals are.

They are growing a bit so I'm thinking of adding an RDS Gateway. If I do so, can I install the same certificate I already have for remote.smithmfg.com on the RDS server? If I want to continue to use both remote access methods, will that work or will I need to setup a different subdomain (pointing to the same static IP) and accompanying SSL certificate for the RDS server? I haven't had to make one of these setups before, so this is probably simpler than I am imagining...but in any event I'm stuck in a loop on how this will work.

 

[YeOldeStonecat]

Generally use wildcard certificates for multiple devices....depends on the host, and their pricing/rules. Some may have a "for use on only 1x server" rule.

The certificates generally get generated based on the FQDN of the host, so...the host name often comes into play, although you can alter this in some CSR wizards.

Single ones are cheap enough, easy enough to just have multiple ones.

I tend to use them on public facing devices that have services exposed via port forwarding. So....for a TSGateway, you'd have one for that of course so that the connect 'tween it and clients is secure. For things like a firewall, secure it if you have web management exposed...so that your login is secure. For VPNs often appliances will generate their own self signed cert for use with the VPN client, but nothing wrong with doing an office 3rd party one.

For "internal" services, like on web interfaces of switches or web interfaces for the firewall, I won't generally do them unless it's a large client and with higher security needs.

 

[Sky-Knight]

Well... first... you need to get your terminology straight. remote.smithmfg.com is not a sub domain, it's a host name.

If it were a subdomain you'd have another level to the name, vpn.remote.smithmfg.com, and you'd have an entire DNS infrastructure to support that now separate but delegated name.

As far as the SSL certificate goes, you need a certificate, private key, and intermediate keys that all match to the name they represent. If you have remote.smithmfg.com working without SSL errors on the Sonicwall, then presumably you've taken a CSR request from that sonicwall, and used it to generate a certificate. If the Sonicwall will let you simply install a certificate with its relevant parts without generating a CSR request, then yes you could have remote.smithmfg.com in that certificate on any number of devices and have it all just work. Because the certificate doesn't care about anything other than the name matching. You can reformat it to any number of different ways to get into any number of different web servers. The only thing that matters is each of them has a valid copy of the certificate, and the client is using the matching name to connect.

The rub is that name is DNS resolved to an IP address, or addresses. And you cannot have any given TCP or UDP port on any given IP address used more than once. So if you need TCP 443 for example, on multiple services, you wind up needing multiple IP addresses. And all of them would have to respond to the same name, which gets ugly.

Normally to save your sanity when you do this sort of thing you swap over to an UCC certificate, because they have mutliple names listed. The problem with those is you need to know what names you want it to be valid for IN ADVANCE. If you ever want to add one, you have to rekey, which means redeploying the certificate every where it's used. So there is an amount of logic to simply keeping single domain certificates on everything, then everything is unique and you only have to touch one system at a time. Note, wildcard certificates work here too, but they do cost more.

Also, if you use Godaddy SSL certificates, be aware their normal certificate is actually good for TWO names. If you ask for a certificate for remote.smithmfg.com, it will also be keyed for smithmfg.com. So you can use it for both names on the same web server easily enough. Though there are some really ugly hairballs that come up when you start firming up your SSL via things like DNS CAA... so careful.

But if I were in your position, I'd use separate certificates for your hosts. And, thanks to IIS sitting on a real server, I'd just use LetsEncrypt for it, why pay for a certificate when you can get a free auto-renewing certificate? But it is an extra layer of complexity to consider too. Your call.

 

[HCHTech]

remote.smithmfg.com is not a sub domain, it's a host name.

Yeah, sorry I wasn't clear in my original post. smithmfg.com is the domain/hostname - points to their website. In my example, remote.smithmfg.com is the subdomain that points to their physical office. I think subdomain is correct here, but I just explained it badly.

If you have remote.smithmfg.com working without SSL errors on the Sonicwall, then presumably you've taken a CSR request from that sonicwall, and used it to generate a certificate.

Yes, that's what I did.

I think from your and @YeOldeStonecat 's posts, since a new RDS Server/TS Gateway would be a different host, it would need (or at least it would be simplier if it had) an individual certificate (obtained the usual way by generating a CSR request from that server itself). I guess my confusion was with how the traffic got there (I could make a new DNS subdomain rds.smithmfg.com, for example, and have it point to one of the free IPs they have, which would be routed by the firewall directly to the RDS server. The endpoint in this case is the server, so that is where the certificate should live, not on the firewall like the certificate for the SSL-VPN traffic.

I think I'd rather just pony up and purchase the cert - The whole Let's Encrypt thing sounds like more work just to save a few bucks. I didn't know you could setup an app to auto-renew them, but I do know they're not the same level of verification as paid certs.

 

[Sky-Knight]

@HCHTech You've got it, though again your terminology is still incorrect on the name. rds.smithmfg.com and remote.smithmfg.com are two different host names. The bit before the first dot is the hostname, the rest is the domain name or name space.

Subdomains are a very specific thing in DNS, and they are how .com forwards requests to our registars that find their way to our public DNS zones. So unless you're delegating a name somewhere, you aren't using a subdomain. And this matters, because at some point you may want to do ad.smithmfg.com for their Active Directory, which would have records like srv01dc01.ad.smithmfg.com and that record may or may not be publicly resolvable. srv01dc01 being the hostname, ad being the subdomain, smithmfg.com being the domain.

Subdomain - Wikipedia

en.wikipedia.org

That's how we're supposed to configure them... not the .local thing that many of us still do. I'm still on the fence about the whole thing, there are ups and downs to both methods.

But whatever, this is semantics, what you're planning will work! The upper level understanding of DNS required to enable unified DNS namespaces for all things isn't really all that important for SMB work. Though if you have a client grow you'll wish you had it... because fixing this stuff is EXPENSIVE. Building new domains just to change the names around isn't terribly fun.

 

[trevm999]

As previously mentioned, the same certificate could easily be used for both, assuming the same firewall with the vpn would also be what forwards the traffic gateway AND they are using different ports, same port gets more complicated.

We also just use Let's Encrypt for RD Gateways servers. As long as you can have port 80 forwarded to the server to do the challenges, it's pretty straightforward.

 

[HCHTech]

Thanks, @Sky-Knight , for the clarification. I am writing a small book (it seems) in response to the names for parts of a URL, but won't have that ready until later as I have an onsite this morning for one of my accountant clients - gotta love after-hours work. Preview: The more I read, the more I think we may have to agree to disagree about the semantics - but it's all good - haha.

 

[YeOldeStonecat]

I recommend you ONLY do port 443...never...ever...ever....ever...forward port 80 to a Window server. Unless you like formatting and reinstalling your server a few days a week all year long due to it being poached.

 

[trevm999]

I recommend you ONLY do port 443...never...ever...ever....ever...forward port 80 to a Window server. Unless you like formatting and reinstalling your server a few days a week all year long due to it being poached.

It would be nice if you backed up blanket statements like that will real information.

Without any context, since a port is just a port, I'm going to assume that you're saying that having port 80 open is painting a target on your back. Now, if you're not being compromised due to not having port 80 open, that means that there is a significant vulnerability in what you're hosting that is still there, just not being targeted.

In the Let's Encrypt setup, the challenge response is hosted by a different service than your RD Gateway, and so just end up exposing some text for the response, so there would have to be some serious vulnerability in that stack in order for it to cause your server to be compromised, and that vulnerability would be there no matter what port.

 

[Sky-Knight]

There's not a problem with having TCP 80 open to IIS...

There is a problem with having that open to IIS that's configured poorly. The defaults usually have all the RDS stuff exposed there too... which means authentication passed in the clear.

But you can change that... I usually have mine open with web.config setup to do permanent redirects to https. Most browsers these days default to https so I don't see much landing there anymore, but it still like having it.

 

[YeOldeStonecat]

It's a free country, you can leave port 80 exposed if you want.
However, TSGateway runs on 443. I prefer not to expose Windows server via port 80 in the first place, but equally or better yet, why open 80 for raping...if it's not even needed in the least bit? You only need 443. Why open more than you need to? I'll stick to just 443, I can't see a single advantage to also adding port 80 except much more exposure to scans and grinding and exploit attacks. //shrug

 

[trevm999]

It's a free country, you can leave port 80 exposed if you want.
However, TSGateway runs on 443. I prefer not to expose Windows server via port 80 in the first place, but equally or better yet, why open 80 for raping...if it's not even needed in the least bit? You only need 443. Why open more than you need to? I'll stick to just 443, I can't see a single advantage to also adding port 80 except much more exposure to scans and grinding and exploit attacks. //shrug

We're much more concerned about having RD Gateway on port 443 than a Let's Encrypt challenge response on port 80. Any RD Gateway without MFA is behind an IP whitelist.

 

[Sky-Knight]

We're much more concerned about having RD Gateway on port 443 than a Let's Encrypt challenge response on port 80. Any RD Gateway without MFA is behind an IP whitelist.

I use VPNs for that, but yes. Also, there's no reason to forward TCP 80 if all you're using is RD Gateway. That is, unless you want to make it easier for your users to get into rdweb. But most browsers default to 443 these days so the 80 service redirecting users to the 443 service is almost a hold over from a bygone age. I still do it though, because i want my users to be able to punch in rdweb.whatever.com and get to the appropriate HTTPs site they are after.

 

[trevm999]

I use VPNs for that, but yes. Also, there's no reason to forward TCP 80 if all you're using is RD Gateway. That is, unless you want to make it easier for your users to get into rdweb. But most browsers default to 443 these days so the 80 service redirecting users to the 443 service is almost a hold over from a bygone age. I still do it though, because i want my users to be able to punch in rdweb.whatever.com and get to the appropriate HTTPs site they are after.

We do port 80 just for let's encrypt challenge. RD web and RD Gateway only responds on port 443.

We also have VPNs, but that gets old pretty fast when you support a company with 20 branches that's continuously acquiring companies. So we're hoping to phase out the VPNs.

Might use Azure App Proxy soon until moving them over to WVD.

 

[Sky-Knight]

We do port 80 just for let's encrypt challenge. RD web and RD Gateway only responds on port 443.

We also have VPNs, but that gets old pretty fast when you support a company with 20 branches that's continuously acquiring companies. So we're hoping to phase out the VPNs.

Might use Azure App Proxy soon until moving them over to WVD.

SSTP? VPN deployed via GPO or InTune Policy is automatic... Especially if that's backed up with DUO or something similar.

Of course DUO directly on RDGateway solves so many problems too.

 

[YeOldeStonecat]

MFA is good for the grinding attacks against weak passwords, and for the phished accounts.
MFA is zero/nothing/useless against OS exploits that attack the OS/listen services directly...totally irrelevant in regards to user accounts/credentials.

For me, the amount of ports open increases the risk. Having 2x ports open....is twice the exposure ...versus having 1x port open. I'll take the "just 1x port" option...cutting my clients exposure down. Since Remote Desktop Client talks via port 443...I have less than zero need for port 80 to be open...so I leave it closed. Back in the day of Small Business Server remote web workplace, I also did the same thing...just had port 443 open/forwarded. Never opened 80. Clients had a shortcut going to httpS://remote.joeblow.com/remote
SBS08 and onward just had RWW run on top of TSGateay anyways...so....we just created Remote Desktop Client shortcuts for the clients..removing a few steps with no need to use the web portal.

 

[Sky-Knight]

IIS 10 doesn't have these problems, unless you failed to patch it oh wait... not even really then!

NVD - Results

nvd.nist.gov

That doesn't mean there aren't things you need to do: https://techcommunity.microsoft.com...ardening-iis-via-security-control/ba-p/329979

And I too have that knee jerk to not want to expose IIS due to its ugly history, this includes nightmares on Windows 8 and its associated Windows Server release 2012. But, as usual the game changes when you're on a properly modern platform, Windows 10 based and patched.

All of the above being said, I will not tolerate open internet access to my Domain Controller, so anyone that was using SBS got VPN'd because of all of the concerns you've expressed. But a server 2016/2019 VPS in an appropriate DMZ? Meh, forward away!

Oh, and one more thing... TSGateway ran via IIS an TCP 443 so it brings all the issues associated with IIS to the fore even if you have the web portion "disabled". But I'll bet you had no problems anyway? No you didn't! Because you patched your stuff!

 

[trevm999]

SSTP? VPN deployed via GPO or InTune Policy is automatic... Especially if that's backed up with DUO or something similar.

Of course DUO directly on RDGateway solves so many problems too.

Most of the branches have site-to-site L2TP/IPsec that we don't manage. We do have client SSTP, but neither go directly to the site with the RDS deployment. Also, sometimes standardized equipment doesn't get budgeted for (though I think this will have to change if we go to WVD) with the acquisition, so sometimes we have to work with thin clients (which sometimes means having to connect to the RD Web feed first in order to properly connect to the deployment). Our goal is to simplify things, and dismantling the current VPN structure is a part of that.

 

[Sky-Knight]

@trevm999 if your VPN investment is still stuck in L2TP/IPSec I can completely understand! Those protocols are ancient, and while well supported, are terrifically annoying at any sort of scale.

 

[YeOldeStonecat]

IIS 10 doesn't have these problems, unless you failed to patch it oh wait... not even really then!

NVD - Results

nvd.nist.gov

That doesn't mean there aren't things you need to do: https://techcommunity.microsoft.com...ardening-iis-via-security-control/ba-p/329979

And I too have that knee jerk to not want to expose IIS due to its ugly history, this includes nightmares on Windows 8 and its associated Windows Server release 2012. But, as usual the game changes when you're on a properly modern platform, Windows 10 based and patched.

All of the above being said, I will not tolerate open internet access to my Domain Controller, so anyone that was using SBS got VPN'd because of all of the concerns you've expressed. But a server 2016/2019 VPS in an appropriate DMZ? Meh, forward away!

Oh, and one more thing... TSGateway ran via IIS an TCP 443 so it brings all the issues associated with IIS to the fore even if you have the web portion "disabled". But I'll bet you had no problems anyway? No you didn't! Because you patched your stuff!

While recent versions of Windows have gotten better, us dinosaurs.....yes...we recall the ugly history, and that stays in our heads.

And you never know when some new exploit will "come out". And if one does, now you have some big emergency on your hands...you have to rush out and apply some rush released patch to a tonna servers. And that's for your managed clients. And then you have your list of unmanaged clients....and their 911's start coming in from poached servers. I remember watching 2008 server pre R2 terminal servers going down rather quickly one year due to that OS level exploit.