Live data from Hacker News

TLS certificates for internal services done right

tuxnet.dev

61–70 of 177 posts

Re: TLS certificates for internal services done right

#61

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.

Is there a commonly used language other than Java that doesn’t just defer to the OS trusted CAs by default?

Re: TLS certificates for internal services done right

#62

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

Thank you, I was unaware of that. It looks like it's already support in the acme.sh client, but there is a Let's Encrypt discussion saying it's still pending at LE:

https://community.letsencrypt.org/t/dns-persist-01-deploymen...

I wonder if the interim version has been rolled out to some CAs.

Re: TLS certificates for internal services done right

#63

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?

Re: TLS certificates for internal services done right

#65

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 root uses the Name Constraints extension, but the default “can sign anything for any host” I fear makes it easy for people to install their own self-pwn device, and probably left the private key lying around on a box exposed to the Internet.

* with some notable root certs that I have… questionable… trust and confidence are not simply controlled by certain state actors.

Re: TLS certificates for internal services done right

#66

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.

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

Re: TLS certificates for internal services done right

#67
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.

Re: TLS certificates for internal services done right

#68
post #38

A Github Action running acme.sh that pushes certs to S3 solves the split dns issue for hosts, which can cause all sorts of weirdness after a while. You can then grab a cert on a schedule and even make them wildcard if you want. Then you will get NXDOMAIN if you are not on the VPN so ideally no public traffic.

DNS-01 validation is way less work than that in my experience.

Thats what this Github Action uses is DNS validation through acme.sh and updating a Route53 domain.

Re: TLS certificates for internal services done right

#69

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.

> Use a central reverse proxy/load balancer for termination.

If you do that anyways, you could also use something like oidc authN/authZ on the reverse proxy level and just expose it to the internet.

You dont even need to self host the oidc idp, you can use Google/Github or even something like ATProto

Re: TLS certificates for internal services done right

#70

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

OP here. Actually I tried to use it but apparently prematurely -> https://github.com/acmesh-official/acme.sh/issues/7085#issue...

Once it's supported I think my next iteration will be DNS persist + internal ip addresses on the public zone.

Thank you all for comments and feedback! It's cool to see real interest in this blog post

Post reply on HN