TLS certificates for internal services done right

Original Article ↗ Hacker News Discussion ↗

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.