Hacker News Reader

Comment by dindresto | Hacker News Reader

I'm using subdomains on a domain I own and request Let's Encrypt certificates with the DNS challenge.

Just beware that the records of the TLS certs are public. So you'll leak a some hostnames. This might or might not be ok.

not if you use wildcard domain in the cert. LE already support wildcard certs

That's not really ideal either...one copy of the cert that isn't protected well becomes a master key of sorts for someone already inside your internal network.

Often inside your network you are more concerned with encryption than authentication. If you "just" need encryption over the wire, wildcard cert's are useful.

Yeah, this is the way to go. If your DNS provider doesn't let you setup limited scope access tokens, then you can use something like acme-dns with delegated dns challenges, as long as you have a single external server.

Then you're routing internal traffic through a public IP? Or do they support wildcard certs?

I have local DNS setup to resolve my personal domains to hosts on my home network. They do support wildcard certs, _only_ if you use some form of DNS challenge.

I'll try to do this for internal IPs using traefik on Kubernetes. Any pointers?

I just use unbound where I have a ansible script install it from the arch repos and deploy a handwritten config file with the dns entries. Then it forwards the rest to my DNS provider. I have my router set the address of that unbound host as the DNS server for my devices via DHCP.

I don't use k8s in my home network (though I do have some podman containers), but there's probably something with more k8s integration you can tie into your k8s ingress setup that I'm unaware of.

SSL certificates contain the name, not the IP. So the IP address can be anything, including internal ones.

I thought Let's Encrypt wouldn't give you a cert if the domain on the cert resolves to a private IP. Good to know - thx.

You just resolve the domain to a private IP on your internal network, Let's Encrypt can see it as whatever you want, for all they care it's 1.1.1.1.

Friendly reminder that 1.1.1.1 is a real, valid, public IP. Seen plenty of networks that don’t recognize this, use it for some internal purpose, and break https://1.1.1.1/

> Seen plenty of networks that don’t recognize this, use it for some internal purpose, and break https://1.1.1.1/

AFAIK Cisco used 1.1.1.1 as an example "dummy" IP in their wireless LAN controller documentation, which of course led to infinite idiots copy/pasting exactly that and setting up broken networks.

My college uses 1.1.1.1 as their iis administration endpoint, I was told the reason was "nobody would guess it so it reduces the number of dumb kids guessing the edu\Administrator domain password". Around the time cloudflare started using it their logs must have skyrocketed.

You can, but you might not want employeerecords.example.com leaking its IP address, even if it is an inaccessible 192.168.10.10. Defense in depth. You can use hosts or internal resolution.

I’ve got a ton of certs from LE where the IP resolves to an RFC 1918 IP

They don't seem to check whether the hostname you're requesting a cert for resolves. At least with certbot, it requests the cert, creates the challenge record, then removes it after receiving the signed cert.

>Then you're routing internal traffic through a public IP?

No, not typically. There's various methods to do the LetsEncrypt challenge/verification that don't require internet connecting the internal host you're generating the certificate for.

The downsides are:

- You can generate a wildcart cert for *.internal.yourdomain.tld. But then, it's a pretty big master key if you lose control of it.

- You can generate a cert-per-server but it exposes your hostnames (at least) in certificate transparency logs, which gives outsiders some view into how big your internal network is, perhaps some detail on what it's like via hostnames, etc. This is worse if you also expose the internal DNS records externally, then everyone sees those records as well, exposing more internal info. You could mitigate these things somewhat with various strategies around hostnames, DNS setup, etc.

> You can generate a wildcart cert for *.internal.yourdomain.tld. But then, it's a pretty big master key if you lose control of it.

For a home network, this is less relevant, since many of the services (and the nginx gateway) are running on the same host as the cert resides on. If they grab the wildcard cert, they're already in a position to mess with the services directly, no SSL MITM needed

Other replies already explained how this is orthoginal to IP addressing, but also there's not many virtuous virtuous things and many downsides about using ambiguous addresses your server to server communications. Also invariably you'll eventually end up networking them in a new way you didn't originally plan. It ends up being bad for security because it breeds unneeded complexity and makes your system harder to understand.

Seconding this approach.

Reply on news.ycombinator.com