July 9, 2026
Private padlocks, public meltdown
TLS certificates for internal services done right
One clever fix for private websites sparked a very public nerd fight
TLDR: The post argues that using a real web certificate plus smart DNS routing is easier than making every device trust a homemade certificate for private tools. Commenters immediately split into camps: some loved the convenience, while others blasted the idea for exposing too much or calling itself the “right way.”
A blog post about securing private company websites somehow turned into a full-on comment-section cage match. The author’s big idea is simple in spirit: instead of using awkward homemade security certificates that make browsers scream, use a real public certificate and quietly send people to the private version of the site when they’re on the company VPN. In plain English, it’s a way to make internal tools like Grafana load with the nice little padlock, without forcing everyone to click through scary warnings.
But the crowd was not ready to just nod along. One side basically said, “Finally, a sane way to stop the endless self-signed certificate misery.” The other side came in swinging: why route private services through something that’s visible to the public internet at all? That was the hottest complaint, with critics arguing this is being sold as “the right way” when really it’s just one way — and maybe not even the safest one for everyone.
Then came the privacy panic. Some commenters hated the idea of exposing internal service names to the outside world, even if the actual service stays locked down. Others flexed their own setups like proud home chefs: wildcard certificates, local-only name tricks, and DNS validation that avoids opening anything publicly. There was even some mild vendor shade — “sorry Tailscale” — giving the whole thing a petty, meme-y sparkle. In the end, the real story wasn’t the config file. It was the classic internet brawl over convenience vs purity, with everyone convinced their padlock is the most righteous one.
Key Points
- •The article contrasts a private internal domain plus self-signed certificates with a public domain plus split-horizon DNS for internal services.
- •It argues that self-signed certificates create trust-distribution problems because each client must be configured to trust them.
- •The proposed setup uses a public hostname that resolves to a public IP externally and an internal IP for VPN-connected clients.
- •The article recommends obtaining trusted certificates from a public CA using ACME and blocking non-VPN traffic with a WAF or equivalent filtering.
- •Its implementation example uses NetBird for VPN DNS features, acme.sh for certificate issuance, and nginx to terminate TLS and proxy Grafana traffic, including WebSockets.