Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS certificates for internal services done right

tuxnet.dev

Post reply on HN
Print view View original

41–50 of 177 posts

Re: TLS certificates for internal services done right

#41

Post by AlexanderYamanu »

throw0101d wrote: post #15
cobertos wrote: post #11

Why not just map the domain to an internal IP and call it a day? Then the only way it can be accessed is through a VPN. Then use a wildcard so none of leaks into cert transparency logs

> Then use a wildcard so none of leaks into cert transparency logs You now also have to build infrastructure to distribute the wildcard from (presumably) central place where you generate it to all the different places where it is desired. And hope the wildcard's private key does not leak from one of myriad of places it now lives.

well, I configure my services te request their own wildcard certs from a caching proxy acme to letsencrypt. Easy peasy.

Re: TLS certificates for internal services done right

#43

Post by llama052 »

jabart wrote: post #38

A Github Action running acme.sh that pushes certs to S3 solves the split dns issue for hosts, which can cause all sorts of weirdness after a while. You can then grab a cert on a schedule and even make them wildcard if you want. Then you will get NXDOMAIN if you are not on the VPN so ideally no public traffic.

DNS-01 validation is way less work than that in my experience.

Re: TLS certificates for internal services done right

#44

Post by llama052 »

xorcist wrote: post #40
maqnius wrote: post #30

Earlier quoted context omitted.

Can you elaborate why one shouldn't use DNS validation for hosts you control in general?

That's not it. If you have an internal network, where every host is provisioned by you, you already control identity. In that case there's no need to validate anything as names, dns records, certificates and anything else should already be in place.

There's certainly something to be said for ease of use and not having to ensure you push trusted certs to every device that touches your internal network.

Unless you enjoy that sort of thing.

Re: TLS certificates for internal services done right

#45

Post by icedchai »

raffraffraff wrote: post #25

Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…

This is similar to what I do, except I have my own authoritative DNS servers instead of Cloudflare.

I'd prefer this over split DNS, any day.

Re: TLS certificates for internal services done right

#46

Post by icedchai »

luckman212 wrote: post #26
raffraffraff wrote: post #25

Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…

Fair, but what about names that are specific enough to give an attacker a clue to a potential attack surface, like "authelia.example.com" - now they know you've likely got an Authelia setup, and can start digging for exploitable CVEs etc. I'm in the process of removing all my individual certs and replacing with a wildcard cert served by Traefik. Is that a bad idea?

Do the names resolve to publicly routeable IPs? If not, I wouldn't worry about it.

Re: TLS certificates for internal services done right

#47

Post by gh02t »

CartwheelLinux wrote: post #10
spydum wrote: post #7

this is all fine and good, if you are okay broadcasting your internal hostnames. I suppose it's a trade off some might make.

There's one way around that which is requesting a wildcard cert, but then that has its own rammifications

There's really two ways, the other is to manage your own CA. But it seems like every browser/piece of software/etc out there is hell bent on making that as difficult as possible. It'd also be nice if it was easier to scope a certificate authority to a specific domain, but support for that is pretty patchy which is functionally the same as no support at all. And that's not to mention software that ignores the system certificate store. Or how tedious and nonstandardized it can be to get a trusted certificate store in a Docker container in cases where you have services that need to trust each other. Or how annoying it is to install your own trusted CA on devices (though, step-cli does help a lot at least on normal computers... phones however...). On and on and on, the barriers to what should be the obvious solution are extremely high.

Re: TLS certificates for internal services done right

#48

Post by graton »

raffraffraff wrote: post #25

Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…

I do the same thing. I'm not worried about them seeing my FQDNs.

I use the form of hostname.int.example.com for everything inside my home network. None of which is accessible to the outside world. I use LetsEncrypt with DNS validation to get the certificates.

Re: TLS certificates for internal services done right

#49

Post by notTooFarGone »

nijave wrote: post #34
jmbwell wrote: post #32

I don’t know much in this space, but I find myself wishing there was a dead simple self hosted CA solution and also that trust on first use (à la ssh) was A Thing for self-managed root certs in client implementations. TOFU is such an elegant, good-enough solution for these use cases. Fixed deployment is always still an option, but in this day and age it feels so much like we are unnecessarily still dealing with solve…

On k8s, there's cert-manager but also you need k8s... Most browsers support trust on first use for leaf certs

Firefox now started that you can't even go on the page on some occasions.

Using a browser in an air gapped environment is so much more pain than it should be.

Re: TLS certificates for internal services done right

#50

Post by bombcar »

EvanAnderson wrote: post #14

The relative proximity of the words "done right" and "split-horizon DNS" makes my insides hurt a little bit. Use DNS validation to allow these internal services to pull ACME certs. There's so much less headache, long-term. Split-horizon DNS (and the tedious make-work it can create when you start needing to mirror public-accessibly records in the private DNS) has always been something to aspire to move away from in my…

Just LE a wild card cert and slap it everywhere.
Post reply on HN