6-Day and IP Address Certificates Are Generally Available

Original Article ↗ Hacker News Discussion ↗

ACME client support and current tooling

  • Not all ACME clients support IP certificates yet; certbot work is in progress, while several others (e.g. lego, acme.sh, cert-manager, some proxies/web servers) already handle IP SANs.
  • There are reports of IP certs working for IPv4 in some servers, with IPv6 support still having quirks.
  • Short‑lived cert “profiles” are already supported by some tooling, allowing separate issuers for long‑lived vs short‑lived certs and gradual migration.

Use cases people see for IP certificates

  • Ephemeral or internal-ish services where provisioning DNS is frictionful or politically slow; being able to do TLS directly to an IP avoids DNS and registrar dependencies.
  • DoT/DoH endpoints: simplifies configuration where today both hostname and IP must be specified; especially relevant for iOS, which historically wanted both to validate.
  • Self‑hosting / bootstrap dashboards: secure a control panel on a raw IP before a user has configured their domain.
  • General desire to rely less on DNS for non-human-facing services; some see this as slightly more “anonymous” or operationally simpler.

Limitations and LAN / DHCP questions

  • Let’s Encrypt requires public, routable IPs and proof of control; typical home/LAN or RFC1918 addresses are out of scope.
  • Dynamic/DHCP public IPs can be used only if you can still prove control; this doesn’t help localhost, but browsers already treat localhost as a secure context.
  • For LAN/internal services, commenters recommend private CAs, split-horizon DNS, or wildcard domains via DNS‑01.

Security, routing, and BGP concerns

  • Some argue IP certs increase exposure to BGP hijacking during HTTP validation; others note that domain-based HTTP validation has similar weaknesses.
  • Discussion touches on RPKI, DNSSEC, and routing security as the real underlying issues; ACME is seen as operating on top of an imperfect substrate.
  • There is skepticism that IP ownership/control can ever be fully robust without deep BGP insight.

6‑day (160‑hour) lifetimes and operations

  • Many are uneasy about very short lifetimes, citing reduced debugging windows if automation breaks and increased operational risk vs 90‑day or upcoming 45‑day norms.
  • Others argue short‑lived certs are the only scalable mitigation for key leaks and help reduce reliance on revocation mechanisms that don’t work well at Web scale.
  • Suggested patterns: run renewal jobs frequently (daily or more) and let the client only renew halfway through validity; some clients can fail over to secondary CAs.
  • The 160‑hour value is chosen to be under the 7‑day “short‑lived” threshold (for looser revocation requirements), leave time for incident response, and avoid weekly resonance (i.e., everything renewing on the same weekday).

Browser/CA governance and TLS client auth

  • Removal of TLS clientAuth from Let’s Encrypt certs is driven by Chrome’s root program requirements against multi‑purpose roots; CAs must comply or lose browser trust.
  • Some see this as CAs being “captured” by browser vendors; others note that all major root programs set conditions and need to push security changes that many CAs/site operators would otherwise resist.

Other wishes and side topics

  • Interest in ACME support for .onion names, since onion addresses already have a strong key binding and HTTPS is required for HTTP/2/3 and many browser features.
  • Desire for a free or low‑cost, automated code‑signing CA in the spirit of Let’s Encrypt; responses note that code‑signing typically demands higher identity assurance and HSM‑backed keys.
  • Some speculate about leveraging IP certs with IPsec/ESP offload, though others think existing VPN/SD‑WAN tooling and social/operational inertia make this unlikely soon.

Overall sentiment

  • Strong enthusiasm for Let’s Encrypt’s continued evolution, especially IP certs solving bootstrap and DNS‑dependency pain points.
  • Simultaneous skepticism about ever‑shorter lifetimes and the broader CA/browser power structure, plus concern that operational burden is being shifted onto “the wider world” of operators.