Live data from Hacker News

TLS certificates for internal services done right

tuxnet.dev

121–130 of 177 posts

Re: TLS certificates for internal services done right

#121
post #110

Earlier quoted context omitted.

> How do clients get the address for a nice domain name without the addresses in public DNS? They don’t. You put the addresses in public DNS.

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

Re: TLS certificates for internal services done right

#122
post #71

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.

Just use IPv6: no "internal" (10/8) or "external" address, just an address. ;)

Re: TLS certificates for internal services done right

#123

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…

Came here to say the same. I use DNS-Challenge rather than HTTP-challenge, and that makes internal servers trivial. You need a DNS provider which supports API calls (I use DNSimple) but the core is all very straightforward. To prevent having to include DNSimple authentication on the client's internal server I have a small API server on the web which does the Acme work.

> You need a DNS provider which supports API calls (I use DNSimple) but the core is all very straightforward.

Library/CLI that speaks the API of several dozen DNS providers so you don't have to re-invent the wheel:

* https://github.com/dns-lexicon/dns-lexicon

Re: TLS certificates for internal services done right

#124

Earlier quoted context omitted.

> 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

He’s using it as a subdomain.

> He’s using it as a subdomain.

Lots of folks were using "dev" as a sub-domain which was fine until ICANN decide to give Google a TLD:

* https://en.wikipedia.org/wiki/.dev

So if you generally had "search example.com" in you resolv.conf, and were in the habit of having "web01.dev" in places, behaviour may have changed if you were suddenly on a machine that had the "search" line missing (or something else).

Re: TLS certificates for internal services done right

#125
post #111

Earlier quoted context omitted.

Which can still cause problems depending on your search domain setting and resolver client

Could you give an example? I'm curious, too.

If you generally had "search example.com" in you resolv.conf, and were in the habit of having "web01.dev" in places, behaviour may have changed if you were happen to be on a machine that had the "search" line missing (or something else).

Re: TLS certificates for internal services done right

#126
post #116

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…

... Could you please provide a solution? What should I do in my homelab? Saying something isn't bad without pointing to right direction makes my insides hurt a little bit.

I feel like I did. >smile> Use DNS validation to allow these internal services to pull ACME certs...

The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.

Re: TLS certificates for internal services done right

#127
post #98

Or... - Don't use split DNS. Don't use any special internal or dev domain. Leave it to your infrastructure to route/NAT those public IPs to your internal network. - Don't use the HTTP-01 challenge. Use DNS-01. - Don't run your own internal CA. Use Let's Encrypt. If you care about name leakage (CT Logs), use wildcard certs. Use a central reverse proxy/load balancer for termination.

>Don't use split DNS So what's your solution when you have a wholly private service that will never have a public v4 address, nor a publicly routable v6? How do clients get the address for a nice domain name without the addresses in public DNS? I use acme.sh with DNS validation, and use common domains that have both public and private services on subdomains. I use split horizon so private.domain.example resolves only…

Wait…what? You have a fully internal service and you dont have an internal DNS server? I guess those exist in theory, but not in practice. :)

If you have a heavy enough tech stack to run fully internal services, than you can also run an internal DNS service (even pihole is enough) and load internal only entries there.

Or add everything to your hosts file if you have a central config service.

Re: TLS certificates for internal services done right

#128

Earlier quoted context omitted.

He’s using it as a subdomain.

> He’s using it as a subdomain. Lots of folks were using "dev" as a sub-domain which was fine until ICANN decide to give Google a TLD: * https://en.wikipedia.org/wiki/.dev So if you generally had "search example.com" in you resolv.conf , and were in the habit of having "web01.dev" in places, behaviour may have changed if you were suddenly on a machine that had the "search" line missing (or something else).

What you describe is a user and resolver configuration problem. There are 100's of TLDs and there's always a chance they will conflict with subdomains, either now or in the future as new TLDs are created. I've been using both "int" and "dev" as subdomains since at least 2000 and never had an issue.

Re: TLS certificates for internal services done right

#129
post #116

Earlier quoted context omitted.

... Could you please provide a solution? What should I do in my homelab? Saying something isn't bad without pointing to right direction makes my insides hurt a little bit.

I feel like I did. >smile > Use DNS validation to allow these internal services to pull ACME certs... The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.

That's for the cert part, yeah, got it.

I thought you have a solution to overcome not having to do split DNS where I define public IP in public DNS and internal IP within some local hosted DNS.

Like how to make so that when 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?

Re: TLS certificates for internal services done right

#130
post #129

Earlier quoted context omitted.

I feel like I did. >smile > Use DNS validation to allow these internal services to pull ACME certs... The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.

That's for the cert part, yeah, got it. I thought you have a solution to overcome not having to do split DNS where I define public IP in public DNS and internal IP within some local hosted DNS. Like how to make so that when 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?

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 "bad split-horizon DNS" world I've seen, time and again, is a corporate network with a MSFT Active Directory named the same as the company's public-facing web property (e.g. "example.com" rather than "ad.example.com"). This creates the need to duplicate all the public-hosted resources into the internal "example.com" zone (and keep them updated when records inevitably change on the public Internet). It's make-work for no practical upside in that example.

Post reply on HN