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.
TLS certificates for internal services done right
121–130 of 177 posts
Re: TLS certificates for internal services done right
#122The 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.
Re: TLS certificates for internal services done right
#123The 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.
Library/CLI that speaks the API of several dozen DNS providers so you don't have to re-invent the wheel:
Re: TLS certificates for internal services done right
#124Earlier 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.
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
#125Earlier 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.
Re: TLS certificates for internal services done right
#126The 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.
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
#127Or... - 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…
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
#128Earlier 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).
Re: TLS certificates for internal services done right
#129Earlier 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.
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
#130Earlier 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?
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.