101–110 of 177 posts
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.
The real answer here is that configuring HTTPS clients to trust a self-signed cert (or signed by an internal CA) shouldn't be as difficult as it is. I find it extremely annoying that every programming language has it's own idea of where certificates should live instead of just checking the os trust store.
Possibly a separate concern, but I have some degree of confidence that the requirements and oversight of the CA/B forum (or whomever else determines which root certs go into bundles) are sufficiently strict, and issuers kept under sufficient scrutiny, that I tend to trust those more than I trust myself to secure my own root CA keys adequately. The ideal would be for people setting up their own PKI to ensure their roo…
Earlier quoted context omitted.
Even if all applications look at the OS trust store, in my experience there's always a gap distributing the CA to every consumer, leading to time spent on debugging from time to time... Maybe that's not the case in perfectly homogeneous or sufficiently small environments where every team uses the same infra / stack.
Yeah, adding CAs to the store sucks. On Linux it needs to be in /etc/ssl/certs (this varies slighly per distribution), which is only writable by root. A single user can't trivially trust a CA, and a great deal of applications/libraries don't support overriding the store's path.
I use a registered domain with DNS validation and then CNAMEs that I resolve locally. Basically: 1. Register a domain ("server.com") and put it on some public DNS that can do DNS validation with acme.sh. 2. Use DNS validation to get a certificate on your domain from Let's Encrypt. You can just grab a wildcard one ("*.server.com"). 3. CNAME all of your services on a public DNS to an internal address ("email.server.com…
I like this approach. Thank you. Would it work if a user's device that is already connected to the VPN, but has custom DNS override to say 8.8.8.8 ? How can I allow my users to be able to use 8.8.8.8 DNS override and still work seamlessly?
It also forces you to use DNS challenges, which means you don't require the publicly route able address.
Personally what I do is: - Predominantly use wildcards
- Run a tiny coredns instance with my A records for a internal subdomain of my normal domain
- Configure tailscale to use the coredns resolver
- Run two haproxy instances, one for internal services, one for public facing. The public facing one can't route directly to the internal services.
When even the obscure DNS provider I'm using is supported for DNS challenges, I really don't see much upside to using HTTP challenges anymore
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…
They don’t. You put the addresses in public DNS.
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…
At that point why not just use the .ts.net addresses Tailscale provides for free?
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…
With one of self hosted services being Adguard-Home can do both ADs blocking and internal DNS... The public DNS records for your "internal use only" domain remain empty.
Earlier quoted context omitted.
He’s using it as a subdomain.
Which can still cause problems depending on your search domain setting and resolver client
Earlier quoted context omitted.
>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…
> 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.