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

51–60 of 177 posts

Re: TLS certificates for internal services done right

#51

Post by stock_toaster »

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

Re: TLS certificates for internal services done right

#52

Post by bruce511 »

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…

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.

Re: TLS certificates for internal services done right

#53

Post by afarah1 »

boscillator wrote: post #19

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.

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.

Re: TLS certificates for internal services done right

#55

Post by patrakov »

otabdeveloper4 wrote: post #24
patrakov wrote: post #12

My preferred procedure is to use DNS-01 validation and have no publicly accessible "A" or "AAAA" record for internal services. Or even a more extreme example: https://crt.sh/?id=27555237869 (sorry for any possible crt.sh downtime) - the domain name in question never existed in public or private DNS by itself. It is used only for a WPA3-Enterprise network, as the CN that WiFi clients expect to be present in the RADIUS…

Sounds bonkers. Why not make an overlay LAN and host your own DNS server in 10.0.0.0/8?

I do have a DNS server in my LAN, with some records served to internal clients only. But the _acme-challenge record needs to be public for the DNS-01 validation to succeed.

The point was that you can obtain a certificate for a domain name without creating any records other than the _acme-challenge TXT record. I.e., that the domain might be completely empty all the time except for this record.

Re: TLS certificates for internal services done right

#56

Post by EvanAnderson »

bombcar wrote: post #50
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.

I get antsy about a private key being in lots of places. You've also got to worry about renewal so you might as well just have "consumer" of the wildcard just provision its own non-wildcard certificate.

Re: TLS certificates for internal services done right

#57

Post by selfmodruntime »

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…

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

Re: TLS certificates for internal services done right

#58

Post by zufallsheld »

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

Well, if your cert-manager distributes its own CA, you'd still need the clients to trust the CA, even in k8s.

Re: TLS certificates for internal services done right

#59

Post by isomorphic »

bruce511 wrote: post #52
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…

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.

I do this exactly, using ACME DNS:

https://github.com/acme-dns/acme-dns

CAUTION, though, the last time I downloaded a binary release, ClamAV triggered on it, so I kept my old version which worked. I was using the 1.0 series (without any problems!), and now it seems the project has picked up development again with a 2.0 series.

Re: TLS certificates for internal services done right

#60

Post by sandermvanvliet »

EvanAnderson wrote: post #56
bombcar wrote: post #50

Earlier quoted context omitted.

Just LE a wild card cert and slap it everywhere.

I get antsy about a private key being in lots of places. You've also got to worry about renewal so you might as well just have "consumer" of the wildcard just provision its own non-wildcard certificate.

I run a reverse proxy that handles the TLS termination for that reason.

Services themselves are constrained to the server, bound to listen on 127.0.0.1 only.

Key is only available to the reverse proxy.

Post reply on HN