Valid TLS for internal services: split-horizon DNS plus a VPN-bound WAF

Serving internal web apps over HTTPS usually forces an awkward choice: use a private TLD like .internal with self-signed certificates that every client must be told to trust, or nag users into clicking past certificate warnings. This walkthrough argues for a cleaner path—keep internal services on a public domain you own and let a real certificate authority handle trust. The trick is split-horizon DNS: public resolvers point grafana.example.dev at a public IP, while VPN-connected clients get the internal IP. Because the name resolves publicly, Let’s Encrypt (via acme.sh) can issue a normal certificate that browsers already trust, eliminating per-device configuration entirely.

The setup layers three pieces: NetBird as the VPN with Custom Zones handling the DNS split, acme.sh in standalone mode issuing certs over the HTTP-01 challenge, and nginx as a reverse proxy. The key defense is binding nginx’s listener to the server’s VPN interface rather than 0.0.0.0, so any request arriving from the public internet is simply refused—a crude but effective WAF. The author frames this as defense in depth: split-horizon DNS is the first layer, and the interface binding holds the line if DNS is bypassed. A cron job runs acme.sh —cron, syncs renewed certs into place with checksum comparison, and reloads nginx; a CAP_NET_BIND_SERVICE capability lets the ACME client’s socat bind port 80 without running as root.

The piece closes with a practical scaling tip: rather than wildcard certificates, which the author avoids on security grounds, use Subject Alternative Names to cover multiple subdomains under a single cert, with CNAME records pointing each service at a shared internal A record. The overall pitch is that centralizing enforcement on one server is far less painful than distributing trust to every machine on the network.