Getting ready to issue IP address certificates

Original Article ↗ Hacker News Discussion ↗

Intended Use Cases

  • Hobby/self-hosting on static public IPs without registering domain names.
  • Temporary or experimental services (dev/test environments, dashboards during DNS restructuring).
  • Appliances and infrastructure that are addressed only by IP, not DNS.
  • Direct connections to DNS-over-TLS/HTTPS servers or auth DNS servers by IP.
  • Potential use for NTS (Network Time Security) to get trusted time when DNS/DNSSEC is broken.

Technical Scope and Limitations

  • Works for both IPv4 and IPv6, but only for globally routable, publicly reachable IPs.
  • Short-lived profile only: 6‑day validity, intended to limit risk with reallocated addresses.
  • Challenges restricted to HTTP-01 and TLS-ALPN-01; DNS challenge is not available for IPs.
  • No private RFC1918 or other non-global addresses; public CAs cannot meaningfully validate “ownership” there.

Security, Identity, and Attack Models

  • Debate over whether IPs should be used as stable identities vs. “keys-as-names” models (WireGuard/Yggdrasil style).
  • Critics argue IPs are mutable, often shared (NAT, cloud), and not good identifiers; fear of new X.509 validation bugs and ecosystem complexity.
  • Supporters say most software they use already handles IP SANs fine and many real deployments have long-lived IPs.
  • Concern about attackers obtaining certs on ephemeral cloud IPs and then releasing them; mitigated somewhat by 6‑day lifetime and existing ability to abuse domain-based names similarly.
  • Some worry this encourages more hard-coded IPs and brittle architectures.

Privacy, ESNI/ECH, and DNS Interaction

  • Suggestion: IP certs could broaden ESNI/ECH deployment and enable hiding SNI even for small sites.
  • Counterpoint: DNS (especially DoH/DoT plus DNS-based ECH keys) is already the main privacy and integrity channel; unclear what adversary is uniquely stopped by IP certs.
  • Discussion of time bootstrapping: using IP-addressed HTTPS servers’ Date headers vs. NTS and DNSSEC’s tighter time requirements; some note hardware clock + DHCP-provided NTP is usually enough.

Private Networks and Home Routers

  • IP certs won’t help with 192.168.x.x/10.x.x.x/172.16.x.x; repeated requests for that were clarified as impossible for public CAs.
  • Suggested workarounds:
    • Private CA and importing its root.
    • Reverse proxies with public-domain certs plus local DNS rewrites.
    • Domains that resolve to private IPs (with caveats when internet/DNS is down).

Certificate Format and Implementation Details

  • Let’s Encrypt is removing CN usage in short-lived certs, relying solely on SAN; most clients are believed to handle this.
  • IP SANs are binary-encoded (no wildcard semantics); wildcard IP certs are not possible by spec.
  • Minor side-thread on a Firefox UI regex bug in IPv6 formatting—affects display, not security.

Other Tangents

  • Some argue Let’s Encrypt efforts would be more impactful for free S/MIME, but others say end-user key management remains a major usability barrier.
  • One commenter frames IP certs as just another vector for TLS exploitation; others note IP certs already existed with other CAs, Let’s Encrypt is simply making them more accessible.