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

141–150 of 177 posts

Re: TLS certificates for internal services done right

#141

Post by graton »

throw0101a wrote: post #95
graton wrote: post #48

Earlier quoted context omitted.

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.

> I use the form of hostname.int.example.com […] Note that int is a valid TLD: * https://en.wikipedia.org/wiki/.int * https://datatracker.ietf.org/doc/html/rfc1591

So? I don't see any issue.

I always use FQDNs for everything.

Re: TLS certificates for internal services done right

#142

Post by EvanAnderson »

jve wrote: post #133
EvanAnderson wrote: post #130

Earlier quoted context omitted.

Hairpin NAT (or "NAT hairpinning") is the term for "...connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address", and the Linux NAT implementation supports it. For a homelab situation split-horizon DNS is just fine. You're going to have minimal duplication of records from the public DNS into the private DNS. The canonical frustrating…

Okay, thanks. I thought split-DNS is a hack even at home. Totally agree on the AD part - luckily we had an option to migrate to different domain and name our AD correctly :)

Ha! AD domain renames in the mid-2000's made a decent chunk of money for me.

Re: TLS certificates for internal services done right

#143

Post by selfmodruntime »

JoeBOFH wrote: post #66
selfmodruntime wrote: post #57

Earlier quoted context omitted.

Also be careful when using split DNS and Tailscale, which increasingly won't work without MagicDNS enabled.

And you still have issues sometimes around dns not able to figure out which interface to use. We had issues around that before.

Yes! That is our exact issue. Do you have any idea on how to circumvent this problem?

Re: TLS certificates for internal services done right

#144

Post by brewmarche »

gh02t wrote: post #47
CartwheelLinux wrote: post #10

Earlier quoted context omitted.

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 c…

If scoping were actually viable, public CAs could also sign your private intermediate CA with a name constraint and it would be trusted everywhere.

Re: TLS certificates for internal services done right

#145

Post by dizhn »

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…

Subdomains with wildcard dns along with wildcard certificates solves that issue. You only expose a wildcard domain with no subdomains.

Re: TLS certificates for internal services done right

#146

Post by maxgashkov »

I've settled on using .internal and Knot as a authoritative NS, step CA + ACME to issue short-lived certs, and a Split DNS resolver from Tailscale as the only external dependency (mostly as a convenience for when I'm on the road).

I do have a luxury of all the homelab VMs being rebuildable via IaC, so I've just injected CA trust at that step.

The biggest PITA so far were 3rd party docker images, each with its own way to inject custom CA.

iOS devices were surprisingly easy to handle.

Re: TLS certificates for internal services done right

#147

Post by xg15 »

stock_toaster wrote: post #51
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…

Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01

At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.

Re: TLS certificates for internal services done right

#148

Post by Walf »

vaughnegut wrote: post #121
Walf wrote: post #110

Earlier quoted context omitted.

Yeah, nah. Won't be doing that.

Why not? It's easy to set up and manage and it just points at an internal IP address

I consider that an unnecessary leak of private topology, it's not info that needs to be public. IPv6 addresses are not really ever internal, and an exploitable vulnerability in a firewall product leads to the possibility of a directly addressable target. Guessing a v6 address without a name pointing to it is impractical at best.

Re: TLS certificates for internal services done right

#149

Post by waynesonfire »

mnahkies wrote: post #105

Personally I think wildcard certs are more secure in many instances - if you're just running one load balancer/reverse proxy then all the private keys are going to the same place anyway. You get the upside of not leaking your subdomains to transparency logs, and having fewer certs to renew. It also forces you to use DNS challenges, which means you don't require the publicly route able address. Personally what I do is…

> - Run two haproxy instances,

This made me consider my haproxy architecture. I use haproxy acl rules and the use_backend directive to enforce security policy and routing. It denies http requests based on source ip address per service (host header)

I think a good middle-ground is to use a single haproxy but two frontends; one binds to the public interface and one for private. haproxy is now no longer responsible for routing, the router is.

Re: TLS certificates for internal services done right

#150

Post by waynesonfire »

thayne wrote: post #71
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…

Another big problem with split-horizon is you can get clients that cache the dns result before connecting to the vpn, then after connecting, can't actually use the service, because it is using the public ip instead of the private one.

> because it is using the public ip instead of the private one.

For this edge case, the issue is not with DNS; it's that the router is not configured to allow internal clients to access the network through the public IP, vis-à-vis hairpin routing.

Post reply on HN