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?
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
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.
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.
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.
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.
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 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.
