The post lays out a way to put valid HTTPS on internal services without teaching every client to trust a private CA. The recipe is a public domain, split-horizon DNS so the same hostname resolves differently inside and outside the network, ACME for certificate issuance, and a reverse proxy or WAF to terminate TLS. The appeal is obvious. Browsers and tools already trust public certificate authorities, so you get working TLS on internal names without touching client trust stores.
That framing did not survive contact with operators. The strongest reaction was that split-horizon DNS is the real source of pain, not the cure. People called out stale DNS caches when devices move onto
VPN,
Tailscale and
MagicDNS edge cases, and the general mess of keeping public and private views in sync. The practical replacement was
DNS-01 validation. You can issue public certificates for internal services without exposing those services at all, and in the extreme case without even publishing A or AAAA records, only the _acme-challenge
TXT record needed for validation. Several people said this is simpler than building special routing or mirrored DNS and works fine with internal IPs, VPN-only hosts, or Tailscale addresses.
The conversation then split around certificate identity and information leakage. One camp was comfortable putting internal names or even
RFC1918 addresses in public DNS as long as the services were unreachable without
WireGuard or another private path. They valued operational simplicity over hostname secrecy. The other camp objected that public certs land in
Certificate Transparency logs and can expose service names like auth gateways or admin tools. Their workaround was wildcard certificates, or skipping public
PKI entirely and using an internal CA on domains like .internal or home.arpa. The pushback there was operational, not conceptual. Internal PKI is still awkward because many runtimes, browsers, containers, snaps, CI systems, and languages do not consistently use the OS trust store.
Where things landed was not that there is one "right" pattern. It was that the proposed setup solves the trust-store problem by shifting complexity into DNS and routing. For small self-hosted setups, DNS-01 with public certs often gets you most of the benefit with less fragility than split-horizon DNS. For environments where you control hosts and care about real internal identity, commenters were blunt that you should join machines to an internal CA and treat that as normal PKI work, not something Let's Encrypt is meant to replace.
tuxnet.dev