Just want simple TLS for your .internal network?

(github.com)

Show context

ndsipa_pomu ◴[22 Oct 24 08:36 UTC] No.41912342[source]▶

I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.

replies(9): >>41912368 #>>41912827 #>>41913126 #>>41913387 #>>41913720 #>>41913826 #>>41916306 #>>41917079 #>>41917804 #

lolinder ◴[22 Oct 24 12:51 UTC] No.41913720[source]▶

>>41912342 #

Yep. I tried the custom-root-CA approach for a long time, but there were just too many problems with it:

* Loading it into every device was more work than it sounds. We have Android, iOS, Mac, Windows, and Linux, all of which have their own rules.

* Even once loaded, some applications come with their own set of root CAs. Some of those have a custom way of adding a new one (Firefox), others you just had to accept the invalid cert each time, and still others just refused to work.

* I deploy my self-hosted stuff with Docker, which means that not only does each device need to have the root CA added to it but every Docker image that talks to the internal network needs to have it as well. This ends up being a mix of the previous two problems, as I now have to figure out how to mount the CA on an eclectic bunch of distros and I often then have to figure out why the dockerized application isn't using the CA.

In the end I settled on a DNS-challenge wildcard SSL cert loaded into Caddy, with Caddy terminating TLS for everything that's on my home server. It's way simpler to configure the single server (or even 2-3 servers) than every single client.

replies(5): >>41913737 #>>41914971 #>>41915668 #>>41916018 #>>41918994 #

1. poincaredisk ◴[22 Oct 24 15:01 UTC] No.41914971[source]▶

>>41913720 #

Historically, before wildcard certificates were suddenly available for free, this leaked all internal domains to the internet, but now it's mostly a solved problem.

replies(3): >>41915477 #>>41918875 #>>41920096 #

2. vegardx ◴[22 Oct 24 15:45 UTC] No.41915477[source]▶

>>41914971 (TP) #

I don't understand why that is such a huge problem. The alternatives have much more severe problems, all from reusing a wildcard in many places to running your own PKI.

replies(1): >>41915630 #

3. NovemberWhiskey ◴[22 Oct 24 15:59 UTC] No.41915630[source]▶

>>41915477 #

It depends on your risk profile, but there are definitely people who'd rather run their own PKI than permit threat actor reconnaissance by publishing internal hostnames to CT logs.

replies(1): >>41918151 #

4. vegardx ◴[22 Oct 24 20:05 UTC] No.41918151{3}[source]▶

>>41915630 #

When this information is useful you've either got fundamental security related issues that needs to be addressed long before this, or you're dealing with threat actors with significant capabilities. In the latter case you've probably already taking this into account when you're creating your stuff, or you have the capability and technical understanding to know how to properly roll out your own PKI.

The overlap of people that suggest that you either run your own PKI or just distribute a wildcard certificate and have the technical understanding on how to do this in a secure way is minuscule. The rest of those people are probably better off using something like Lets Encrypt.

replies(1): >>41920091 #

5. peanut-walrus ◴[22 Oct 24 21:24 UTC] No.41918875[source]▶

>>41914971 (TP) #

So what? Do you keep secrets in your domain names?

6. ranger_danger ◴[23 Oct 24 00:09 UTC] No.41920091{4}[source]▶

>>41918151 #

I still think it's a good idea not to expose more information than necessary, mostly for the reasons we can't think of.

Also I wouldn't be surprised if Let's Encrypt/ZeroSSL were compromised.

replies(1): >>41922276 #

7. ranger_danger ◴[23 Oct 24 00:10 UTC] No.41920096[source]▶

>>41914971 (TP) #

> suddenly available for free