TLS certificates for internal services done right

Original Article ↗ Hacker News Discussion ↗

Efforts to secure internal services with TLS expose a trade-off between convenience and control: some favor using public certificate authorities like Let’s Encrypt via DNS-01 challenges, split-horizon DNS, and central reverse proxies, while others insist internal CAs and mTLS are the only sound approach. Commenters highlight practical pain points such as leaking internal hostnames into certificate transparency logs, the complexity of managing private CAs and OS/browser trust stores, and the fragility of split-horizon DNS. No single “right” pattern emerges; instead, people weigh operational simplicity, privacy, and security posture differently depending on scale, threat model, and how much they control client devices.

Split-horizon DNS vs alternatives

  • Many criticize split-horizon DNS as brittle and high-maintenance, especially at scale (duplicated records, caching weirdness, VPN routing issues).
  • Others say it’s fine for small/home labs and can be combined with hairpin NAT; the real pain is large corporate setups where internal and public zones share the same name.
  • Some explicitly refuse to use split DNS, preferring single public zones with internal IPs or overlay networks.

ACME, DNS-01, and automation patterns

  • Strong preference for DNS-01 validation over HTTP-01 for internal services.
  • Common patterns:
    • Use a public domain with DNS APIs to obtain certs (often wildcard), then point names to internal IPs.
    • Use CNAME “_acme-challenge” aliasing to delegate DNS-01 to a separate zone/provider or to tools like acme-dns.
    • Central ACME helper services or GitHub Actions that own DNS credentials and issue certs for internal hosts.
  • Interest in the upcoming DNS-PERSIST-01 challenge to reduce need for dynamic DNS updates, though support is still limited.

Public CAs vs internal CAs

  • One camp: “Just run an internal CA, sign internal certs, and trust that CA on your devices.” Seen as the clean cryptographic solution.
  • Counterpoints:
    • Distributing and managing trust anchors across heterogeneous OSes, languages, containers, and browsers is painful.
    • Some argue public CAs (e.g., Let’s Encrypt via DNS-01) are simpler operationally, especially when you don’t fully control client devices.
    • Concerns about rate limits and trust semantics (public cert only proves domain control, not organizational identity).

Wildcard certs, CT logs, and hostname/privacy concerns

  • Some worry that non-wildcard public certs expose internal hostnames via Certificate Transparency logs; wildcard certs mitigate this but centralize key risk.
  • Others are unconcerned about leaking generic home hostnames or say attack surface matters more than obscurity.
  • Debate over whether putting internal IPs and hostnames into public DNS is acceptable; some see it as harmless, others reject it outright.

Client trust stores and tooling fragmentation

  • Multiple comments lament that configuring clients to trust internal CAs is harder than it should be.
  • Different ecosystems use different trust stores (OS, Java, browsers, Node, Python/certifi, containers, snaps), forcing repeated CA installation.
  • This complexity is a major reason some favor public ACME certs even for purely internal services.

Security models and access patterns

  • Some advocate “BeyondCorp/zero trust” style: mTLS, device certs, and authenticated reverse proxies instead of VPN plus split DNS.
  • Others rely on VPNs (WireGuard, Tailscale) plus internal DNS, or central reverse proxies/load balancers terminating TLS and routing to internal services.
  • Opinion remains divided on whether using public certs for internal-only high-value services is appropriate; some call it “bogus,” others ask why it would be harmful.