Live data from Hacker News

Should you use Let's Encrypt for internal hostnames?

shkspr.mobi

151–160 of 198 posts

Re: Should you use Let's Encrypt for internal hostnames?

#151

I will never understand the obsession people have with hiding their private server names. If somebody gets any access to your local network, there are plenty of ways to enumerate them, and if they can't get access, what's the big deal? I get that you may want to obfuscate your infrastructure details, but leaking infrastructure details on your server names is quite a red flag. It should really not happen. (Instead, yo…

Ingrained practices are the sort of thing that change one funeral at a time (see constant password rotation).

It's a reasonable mitigation for certain environments and does leak information that makes structuring attacks easier, but it's certainly not a hard wall of any sort. The main problem for most people is articulating the realistic threat models they are trying to address and because that rarely resolves well assuming the conversation is had at all, there is little rational pushback against "everything and the kitchen sink" approaches based on whatever blog the implementer last read.

Personally I tend to advocate assuming your attacker knows everything about you except specific protected secrets (keys, passphrases, unique physical objects) and working back from there, but that's a lot of effort for organizations where security is rarely anything but a headache for a subset of managers.

You'll see similar opinions about things like port-knocking puzzles and consumer ipv4 NAT, which provide almost zero security benefit but do greatly reduce the incidence of spurious noise in logs.

Re: Should you use Let's Encrypt for internal hostnames?

#152

Earlier quoted context omitted.

We're a long ways away from name-constrained intermediaries being viable from a regulatory and technical perspective. I'd explain, but commenter in a thread linked to the one you posted has a pretty detailed explanation already: https://community.letsencrypt.org/t/sign-me-as-an-intermedia...

From that it looks like the main issue is regulatory requirements that force CAs to log all issued certificates via CT (certificate transparency) logs. Given that this is the very thing we're trying to avoid with a private CA ("CT" and "leaking internal hostnames" are functionally synonymous) we seem to be at an impasse at the level of base requirements. Maybe an IP constraint that restricts certs to only be valid in…

You can still use wildcard certificates to avoid leaking the entirety of your private hostnames, while providing transparency around the "authority" portion of your domains.

Re: Should you use Let's Encrypt for internal hostnames?

#153
It's possible to configure DNS to make a public domain point to an internal IP and register a certificate for that domain.

For example, you can register a certificate for local.yourcompany.com and point local.yourcompany.com to 127.0.0.1 to get HTTPs locally. The same could be done for internal network IPs.

It wouldn't work well with Let's Encrypt because their bot would just end up talking to itself in this scenario.

Of course you could also use my side project (expose.sh) to get a https url in one command.

Re: Should you use Let's Encrypt for internal hostnames?

#154
post #35

Earlier quoted context omitted.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

I'm a fan of both Caddy and Tailscale; any chance you have any devnotes to share on your setup?

My notes were pretty rough but I've tried putting them into a gist here:

https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2...

Which covers using step-ca with Caddy to get TLS certs via ACME for subdomains, and protecting internal services using client certificates/mtls

I then install Tailscale on the host which is running the docker containers, and configure the firewall so that only other 100.* IP addresses can connect to ports 80/443/444. The combination of VPN+MTLS mitigates most of my worries about exposing internal subdomains on public DNS

Re: Should you use Let's Encrypt for internal hostnames?

#155

Earlier quoted context omitted.

We're a long ways away from name-constrained intermediaries being viable from a regulatory and technical perspective. I'd explain, but commenter in a thread linked to the one you posted has a pretty detailed explanation already: https://community.letsencrypt.org/t/sign-me-as-an-intermedia...

From that it looks like the main issue is regulatory requirements that force CAs to log all issued certificates via CT (certificate transparency) logs. Given that this is the very thing we're trying to avoid with a private CA ("CT" and "leaking internal hostnames" are functionally synonymous) we seem to be at an impasse at the level of base requirements. Maybe an IP constraint that restricts certs to only be valid in…

I wouldn't say that's even the main issue, but it _is_ probably one of the more difficult ones to solve assuming that just logging all certs publicly the same way every other CA does isn't an acceptable solution for you.

The bigger issue right now is this:

> under current BRs, a name constrained subordinate has to meet all the same requirements an unconstrained subordinate does, which means secured storage and audits

Basically, even a name constrained intermediate CA is subject to all the same regulatory requirements as a trusted root CA. From a regulatory compliance perspective it'd be pretty much equivalent to operating your own globally trusted root CA, with all the auditing and security requirements that go along with that. And if you ever screw up, Let's Encrypt, as the root CA your CA is chained to, would be held responsible for your mistakes as required by the current BRs.

Basically, it's not happening anytime soon without some serious changes to the Baseline Requirements and web PKI infrastructure.

Re: Should you use Let's Encrypt for internal hostnames?

#156

> The only real answer to this is to use Wildcard Certificates. You can get a TLS certificate for *.internal.example.com Does Let's Encrypt support Subject Alt Names on the wildcard certs? My experience suggests that wildcard certs work, but require a SAN entry for each "real" host because browsers don't trust the CN field anymore. e.g., my *.apps.blah cert doesn't work unless I include all of the things I use it on…

"Or am I completely wrong about the SAN requirement?"

Not w/r/t Chromium.

https://web.archive.org/web/20170611165205if_/https://bugs.c...

https://web.archive.org/web/20171204094735if_/https://bugs.c...

In tests I conducted with Chrome, the CN field could be omitted in self-signed server certs without any problems.

Re: Should you use Let's Encrypt for internal hostnames?

#158
post #144

A public CA is for having a third-party entity so two different parties do not need to trust each other. So, the answer is no. Why would you even consider this for internal communication?

Installing a root CA on devices is risky. From the article: > It means your employees aren't constantly fighting browser warnings when trying to submit stuff internally. If your employees gets a habit of ignoring certificate warnings then you have much bigger problems than leaking internal domain names.

Clients should not ignore the certificate warnings. You install the certificates on the client machines.

Re: Should you use Let's Encrypt for internal hostnames?

#159
post #56

Why not just be your own signing authority for internal domains? You can propagate your toplevel public cert with most enterprise network provisioning tools.

Running your own PKI is fairly straightforward, particularly with tools like cfssl at your disposal. But running your own PKI properly is quite hard. Let's Encrypt gives you top tier PKI management for $0.

> Let's Encrypt gives you top tier PKI management for $0.

Ok, but it fails at one of the requirements.

Re: Should you use Let's Encrypt for internal hostnames?

#160
post #43

Can lets encrypt issue multiple wildcard certs for different subdomains like *.banana.example.com and *.grapefruit.example.com Then you could give each server a different wildcard cert without exposing the full name to the certificate log: exchange.banana.example.com log4j.grapefruit.com Ugly, but functional. Alternatively should the certificate transparency log rules be changed to not include the subdomain? Maybe wh…

> Alternatively should the certificate transparency log rules be changed to not include the subdomain? Maybe what matters is that you know that a certificate has been issued for a domain, when, and that you have a fingerprint to blacklist or revoke. Knowing which actual subdomain a certificate is for is very convenient, but is it proportionate?

That was a big debate in the CA/B Forum when CT was created; the current behavior is a deliberate choice on the part of the browser developers, which they will probably not want to revisit.

Post reply on HN