TLS/SSL certificates on (internal) LAN

questions tips
, ,
1

Every so often the question is raised about how to do TLS (SSL) on a LAN (internal) network.

While there’s no perfect solution, it can be done by someone who has a smattering of networking knowledge (at least a basic understanding of DNS).

Several years ago I did a presentation on clarionlive showing two solutions:

  1. A self-hosted certificate authority on an Active Directory domain. The downside of this is that it only works for domain computers (not phones or other devices) and requires more IT skill.
  2. Using a commercial certificate and manipulating DNS. This works for ALL devices on a domain. It’s easiest if your LAN has its own DNS (which is a requirement for Active Directory) but can also be used by tweaking one’s internet DNS and configuring port-forwarding on the LAN’s internet firewall.

For option 2 I HIGHLY recommend a purchased certificate, which can cost as little as $13 per year. (Or maybe $60 for a wild-card if you need to support multiple servers). Going through gymnastics to try to obtain Let’s Encrypt certs every 60 to 80 days is not worthwhile if your IT staff (or you) get paid more than $7 per hour!

In case it might be helpful as a reference, I’m attaching the slides I used for that webinar… outlining both approaches.
And this is a link to that webinar: ClarionLive!

Cheers,

jf

Certificates.pdf (491.4 KB)

2

This technique, and others for LAN use, are covered at the start of this webinar; https://www.youtube.com/watch?v=Z10I-qiIoB4

3

How does IPSEC fit into all of this?

4

Bruce -
yes…
BUT…

Actually, watching that youtube video was what prompted me to re-post this.

As people who work in technology, we know that often the devil is in the details.

The DNS trick you explain in that NetTalk webinar (and that I’ve seen you describe various times before) is an offshoot of what I showed.

But NOT the same and much less scalable.

Your version of “my” DNS solution involves tweaking an external DNS 4 or 5 times a year in order to get a free Let’s Encrypt cert. And either using port-forwarding or else loopback in the router.

Mine involves a commercial cert, no port-forwarding, no loopback. Those are significant differences.

Your variant is probably the best solution for some businesses. Even there, I’d personally go for the paid 1-year certificate rather than the Let’s Encrypt that expire in 90 days.

The guy you were helping in the most recent webinar has a hosted public web server that wouldn’t work for getting his Let’s Encrypt certs because he can’t run a Windows app.
Spinning up an AWS box for a half hour every 80 days just to acquire the Let’s Encrypt cert is awfully convoluted.
If his network hosts its own internal DNS, none of that is necessary and his existing hosted server will work just fine for purchasing a commercial cert.
Even without his own DNS he could still use his existing hosted domain to purchase a commercial cert and then do your trick with the public DNS and internal router loopback. But if his network is using Active Directory, it WILL have its own DNS.

The commercial cert solution I described in the clarionlive webinar is different from the one that you show.

I’m an administrator on the medium-size network where I contract. We have between 900 and 1000 employees in about 20 facilities. We have a variety of internal web servers - IIS, SSRS, Apache, and NetTalk. It is a medical environment that has regular security audits.

On our network we’ve configured dozens of split DNS domains to support servers that require a commercial cert.
For each server, it involves a one-time item setup in our internal DNS. Then doesn’t need to be touched again.
It requires no port-forwarding to be configured through our firewalls.
It requires no loopback in the firewalls.

Once a year we buy a wildcard certificate using a publically-registered domain name. I then install the cert on our servers.

I take no credit for this brilliant technique. Our IT director learned of it from a post on spiceworks (where the cool kids congregate) that links to this article: Windows - Setting Up Split DNS | PeteNetLive

For our servers that are only accessed by domain-joined computers I’ve built an internal certificate authority (with offline root) that’s trusted in Active Directory. That’s convenient because those certs work with the actual server names and no DNS tweak is required.

Even much smaller networks with only a single site can benefit from this split DNS trick with a commercial cert if they’re running Active Directory.

Let’s Encrypt is a great tool.

Router loopback is a great tool if you’ve only got one router and one or two servers.

Not all pegs are round :wink:

Cheers,

jf

5

How does IPSEC fit into all of this?

I don’t think it does, Rick.

What I posted is about certificates for servers that run inside a LAN and need to provide HTTPS connections to internal users. The challenge being that you can’t buy a certificate for “10.12.1.123” or for an internal domain name that isn’t publically registered.

Unless you’re talking about configuring VPNs? (That’s been my only experience with IPSEC).
These are a couple of interesting articles on IPSEC vs TLS for VPNs:

6

Oops, missed your point. I thought you were just trying to encrypt all traffic, not provide HTTPS support.

7

no, the port-forwarding and router loopback were for a different technique. They are an alternative - if you have those then you don’t need to play games with DNS at all - you can simply assign an internet-valid-domain to the LAN server and everything (LE, local browsing etc) just works for inside and outside. That’s the best version, but requires the port-forwarding which may not be possible.

I agree that a commercial certificate would only need to happen once a year, not 5 times a year, and that’s a significant improvement.

In the webinar, in Mike’s case, there isn’t Active Directory.

8

Hi,

Maybe this is also a solution.

We used a Sandbox VM where we installed Certify The Web - simple free certificates for IIS and more, powered by Let’s Encrypt and other ACME CAs

So this machine is working in a dmz and have a mapped drive to the certificate folders of our webservers.
So all our webservers are just working internally but get the lets encrypt certificat from the sandbox machine. So for every domain there is a separated mapped drive. So all 90days the certficates are renewed automatically.

Regards :slight_smile:

9

Bruce,

The DNS technique with a commercial cert doesn’t require Active Directory, just access to DNS.
I was guessing that for a campus large enough to have a custom app for a roving maintenance staff it’s not likely that they’re using a simple peer-to-peer workgroup. Maybe they are.

You’ve hosted enough webinars where this question has been raised that I thought it worthwhile to congregate some information here. I appreciate your enthusiasm for Let’s Encrypt (that’s what my simple personal hosted domains use). I don’t think it’s generally the best choice for LAN devices.

Although… the Certify The Web link Rob posted presents an option of which I was not aware. I’m going to learn more about that.

Cheers,

jf

10

Very cool, Rob! Thanks. I wasn’t familiar with this option.

jf

11

Yes, you can use TLS/SSL certificates on an internal LAN to secure communication and prevent unauthorized access. If you’re looking for affordable options, you can check providers like CheapSSLWEB. com for cost-effective SSL certificates that work for internal and external environments. Hope it helps!

12

I’ve not used the TLS on Lan, described here, but why dont you lock down the lan switchs to block unknown macID’s and port forward through firewalls?

I know MacID’s can be spoofed, but to hide the manufacturer of the device, I changed the macID’s which then had to be allowed.

Likewise Vlan was in use and (port) ACL’s were in use. Sure its a pain doing all of that, but your switch logs can show up when a device or vlan has been compromised quite quickly.

I’m not convinced TLS on Lan is the way to go, mainly because IPS/IDS systems cant monitor the data in the packets…

13

A. I contract at a medical center where the lawyers and compliance people require outside companies to do penetration and security checks on our system.

B. What you suggest about white-listing MACs and tinkering with switches might work on a small LAN. Ours isn’t huge, but when you’ve got more than a thousand devices, more than 20 sites connected by routers, and some devices being replaced every week, tweaking each switch to allow only certain MACs would be tedious.

C. What you suggest about white-listing MACs wouldn’t mitigate against somebody who was somehow able to install a packet sniffer on an approved device (although our Group Policy lockdowns are pretty tight.)

D. My original post was meant to address a question that arises with sufficient frequency that I thought it was warranted - how can one use TLS on an internal LAN when commercial (i.e., trusted) certificates will not issue for an IP address or non-public domain.

E. There are many fish in the ocean.

14

In the 4 years since this thread started, the solutions have changed. These days, with dns-challenge support, creating a certificate for a LAN server is pretty trivial.

Its covered in the NetTalk docs, but boils down to using a DNS entry with a LAN IP address. We’re doing it all the time now for on-prem installs.

Richard, TLS on the LAN us important to prevent data being sniffed by other machines on the LAN. Given the prevalence of wi-fi support this is especially necessary.

15

Well, any self generated certificate and key pair will provide encryption. The problem is that if that certificate is not trusted nor signed by a trusted certificate you will receive a warning in your browser and when not using a browser but some other software your connection may, or these times will, fail. I have run across this issue when installing Hadoop cluster with Kerberos support using self signed certificate.
The solution I came up with may be a bit complicated, but I needed to use internal domains with a .local suffix so I could not buy any certificate for these. Therefore I built my own CA ( Cetrificate Authority ) to sign my certificates and added the CA cert to trusted on my client machines.
On Windows you can do it with

certutil -addstore -f "ROOT" <cacerts location>

on Mac

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain <cacerts location>

and on Linux ( Debian)

sudo cp <cacerts location> /usr/local/share/ca-certificates/foo.crt
sudo update-ca-certificates

for JVM

keytool -import -alias <your alias name> -keystore <cacerts location> -trustcacerts -file <certificate location>

You could probably do this with Active Directory policies, I did that with CFEngine.

The benefit is that once you add your own CA to trusted you can sign any certificate you want and it will be trusted by all machines in your LAN.

I undergo TISAX audit every year and I pass, although they always say it’s just a recommendation :wink:

16

Sure, you can trust self-signed certs one machine at a time.

In a network that uses Active Directory, you can use Group Policy to have a self-signed certificate and any sub-certificates generated from it trusted by all machines on the network.

But that won’t work if people are accessing an app using phones or tablets that are not domain members. Or, at one time ChromeBoxes (although I don’t know whether that’s still the case.)

So in our Active Directory LAN/WAN we have a mixture of certs generated by our AD certificate authority and commercial certs on the few servers that require them.

17

True, but not sure what you want to achieve. If these “people” are outside of your organisation they would use public domains where you can obtain LetsEncypt or any other certificate. If they are employees they still have to have some kind of VPN on their mobile devices so you need to set it up. As a part of the setup you can add your CA cert as trusted. One of my clients, a top 10 bank worldwide, used to have a custom domain for their internal systems and that was 10 years ago. When I was opening these sites I got a certificate warning but not their employees. You either add the CA as trusted or not. If you do it will work. No chances for the outside world unless you speak to the majors.

18

Managers phones and doctors’ tablets are not joined to the domain (controlled by Active Directory.).

We have a need for non-self-signed certs for some purposes.

You don’t.

Fine.