TLS for a Bare IP: What Let's Encrypt's Free IP-Address Certificates Change for Self-Hosted Deploys

Paste a fresh server's IP address into a browser over HTTPS and you get the error every self-hoster knows by heart: the connection is encrypted, but the certificate names something else, so the browser refuses to trust it. For a decade that was simply how the free web PKI worked — Let's Encrypt issued for domain names only, and a bare IP got a self-signed cert, a click-through warning, or a paid exception. That changed in stages: Let's Encrypt issued its first IP-address certificate in July 2025, and on January 15, 2026, IP certificates went generally available — free, ACME-automatable, for IPv4 and IPv6. The recipe is short: request the shortlived profile, prove control with http-01 or tls-alpn-01, and automate renewal, because the cert lasts about six days.

The verdict for a self-hosted PaaS: this is a bootstrap and infrastructure primitive, not a tenant-facing one. The three places it earns its keep are a freshly provisioned node's bare IP during the window before DNS exists, the platform's default IP-fallback vhost, and infrastructure endpoints addressed by IP. Tenant production traffic still wants a real domain. The rest of this post shows the exact mechanics, the adoption data proving this is now the default path, what self-hosters did before, and the honest limits.

What actually shipped, and the constraints that come with it​

The timeline matters because it explains the shape of the feature. Let's Encrypt announced the plan in January 2025, issued the first production IP cert on July 1, 2025, rolled it out to allowlisted partners through the second half of the year, and opened general availability on January 15, 2026. IP support was deliberately gated on short-lived certificates: as a matter of policy, any Let's Encrypt certificate covering an IP address must use the shortlived profile. The reasoning is straightforward — IP addresses are more transient than domain names, so re-validating every few days instead of every few months keeps stale bindings from lingering.

The mechanics that matter for automation:

Two rows in that table do most of the work. The 7-hour authorization reuse means shortlived renewal is a standing validation conversation with the CA, not a cached permission — your http-01 or tls-alpn-01 path must be permanently healthy, not just healthy on issuance day. And Let's Encrypt's own docs carry the warning honestly: "We recommend this profile for those who fully trust their automation to renew their certificates on time. This profile is not for everyone." For a PaaS that already automates per-tenant issuance, that bar is cleared. For a human with a cron job they set up once and forgot, six-day certs are a footgun.

One more piece of context: shortlived IP certs are also a preview of where the whole ecosystem is going. Let's Encrypt has announced the default lifetime drops from 90 days toward 45 days over the next few years. Building renewal automation that comfortably handles six-day certs today means the 45-day future arrives as a non-event.

The market already flipped: 99% of new IP certs come from Let's Encrypt​

The adoption data is unusually crisp, thanks to a September 2026 landscape study by Yevheniya Nosyk (KOR Labs, Internet Society Pulse Research Fellowship) — the first systematic measurement of CA-issued IP certificates. Three numbers tell the story:

• 2025 was a duopoly. Of 518K unique IP certificates observed in 2025, ZeroSSL and Let's Encrypt together issued 96.44%. ZeroSSL led on breadth (313K certificates covering 208K unique IPs, mostly 90-day certs), while Let's Encrypt's 186K certificates covered only 4.6K unique IPs — the fingerprint of the allowlist era, when a handful of partners issued repeatedly against a few hosts.
• 2026 is a rout. A 72-hour Certstream sample in July 2026 collected 372K IP-bearing certificates: 99.21% from Let's Encrypt, 0.76% from ZeroSSL. Once GA opened the door, issuance consolidated onto the free automated CA almost immediately.
• Deployment is real, not just issuance. Active scans found 38K hosts serving trusted IP certificates across 21 ports. Ports 443 and 8443 account for 91.1% — ordinary HTTPS — with port 853 (DNS-over-TLS/QUIC) in third place, exactly the infrastructure-services use case Let's Encrypt named in its announcement.

For a platform deciding whether to build on this: IP certificates are no longer an exotic corner of the PKI. They are a mainstream, Let's-Encrypt-shaped issuance flow with the same ACME tooling you already run.

What self-hosters did before, and what each workaround cost​

To price the new primitive correctly, it helps to remember the three workarounds it replaces:

1. Self-signed certificate plus click-through. openssl req -x509 with an IP: SAN takes thirty seconds and produces a cert no browser trusts. Fine for a personal homelab; unacceptable the moment a second human, an API client, or a health checker touches the endpoint. Every consumer needs an exception, an --insecure flag, or a private CA install — and --insecure has a way of surviving into production.
2. Wildcard-DNS hostname plus a domain cert. Services like nip.io and sslip.io resolve 203-0-113-10.sslip.io back to 203.0.113.10, so you can complete an http-01 challenge and get a normal domain-validated cert for an IP you have no DNS for. This works and remains useful, but it routes your bootstrap trust through a third party's DNS zone: if their nameservers hiccup, your issuance and your clients' resolution both break, and some corporate resolvers block these zones outright.
3. A commercial IP certificate. Before July 2025, a handful of CAs (PositiveSSL, Sectigo, GeoTrust) sold IP certs at roughly $40–90 per year per address. At fleet scale — dozens of nodes, each needing its own cert — that is a line item and a procurement process for what should be an API call.

The Let's Encrypt version removes the money, the third-party DNS dependency, and the trust exception in one move. What it charges instead is automation discipline: six-day lifetimes with near-zero authorization reuse.

Where a self-hosted PaaS actually uses one​

Here are the three places IP certs earn their keep on a git-push platform, plus the lines not to cross.

1. Node bootstrap, before DNS exists. A freshly provisioned Hetzner node has a bare IP and nothing else. During the bootstrap window — the orchestrator's agent checking in, the node pulling images, internal APIs coming up — every connection either skips verification or fails it. An IP cert minted at provision time gives that window real TLS: the agent can pin its check-in to a publicly trusted cert for the exact IP it was told to call.

Once the node's DNS record propagates, the regular domain cert takes over and the IP cert is simply not renewed. This is the highest-value use because it closes a window that previously had no good answer.

2. The default IP-fallback vhost. Someone always pastes the platform IP into a browser — a tenant debugging DNS, a scanner, a curious operator. Let's Encrypt explicitly named the hosting-provider default page as a use case: today that paste produces a certificate error, which trains users to click through warnings on your infrastructure. Serving a valid IP cert on the fallback vhost turns that moment into either a clean default page or a clean redirect to the real domain. The same cert covers HTTPS health checks and load-balancer probes that address backends by IP without SNI tricks or verification skips.

3. Infrastructure endpoints addressed by IP. DNS-over-HTTPS/TLS resolvers, internal APIs called by numeric address, device and IoT callbacks hitting a fixed IP — anywhere the client knows an address, not a name. The ISOC data shows port 853 already in third place among IP-cert deployments, confirming this is where operators reached first.

And the honest non-uses, stated plainly:

• Tenant production traffic still wants a real domain. An IP cert authenticates the machine, not the tenant's brand, and IPs get renumbered. The tenant's <name>.onbex.co subdomain or custom domain remains the right identity the moment anything is user-facing.
• There is no wildcard-equivalent for a range. Twenty-five names per cert, each an explicit IP. A /24 of nodes needs many certs, each renewed on the six-day cadence — which is fine if issuance is API-driven per node, and miserable if it is manual.
• Six-day renewal is mandatory automation, full stop. With 7-hour authorization reuse, a broken validation path surfaces within days. If your platform cannot already issue and renew tenant certs unattended, fix that before adopting IP certs anywhere load-bearing.

How to get one today​

The recipe has three ingredients: an ACME client that speaks the profiles extension, the shortlived profile selected, and an http-01 or tls-alpn-01 responder on the IP.

With Certbot 5.3 or newer (support landed in March 2026), the issuance looks like this:

sudo certbot certonly --preferred-profile shortlived \
  --standalone --ip-address 203.0.113.10

The --ip-address flag requests the IP SAN; --preferred-profile shortlived selects the mandatory six-day profile. Certbot's renewal timer then handles the cadence — verify it actually runs, because a lapsed timer that was merely embarrassing on 90-day certs is an outage on six-day ones.

acme.sh users pass the profile through with --certificate-profile shortlived, and Caddy-based setups have documented requesting IP certs under the shortlived profile — DigitalOcean's 1-click images, for example, have Caddy fetch a Let's Encrypt cert for the droplet's own IP at first boot. Expect rough edges in any client that assumed identifiers are always DNS names; the failure mode to watch for is the client requesting the classic profile (or none) for an IP identifier and getting the order rejected by the CA.

For a PaaS wiring this into provisioning, the cleaner pattern is usually the platform's existing ACME client (often lego under Traefik, or cert-manager) pointed at the node IP with the profile set — the same renewal loop that tends tenant certs, extended to one more identifier type. Keep the IP cert's lifecycle tied to the node's: issue at provision, renew while the node lives, abandon at decommission. Nothing about a decommissioned node's cert needs revoking attention — it expires within days by construction, which is precisely the security property short-lived certs were designed for.

Six days as a feature, not a bug​

Step back and the design reads clearly. The CA/Browser Forum's long squeeze on lifetimes, Let's Encrypt's march from 90 days toward 45, and the mandatory six-day window on IP certs all push the same direction: certificates as continuously refreshed attestations rather than quarterly paperwork. Revocation — the PKI's least reliable mechanism — matters less when nothing lives long enough to need revoking. IP addresses, the most transient identifiers of all, simply got the end-state treatment first.

For teams running their own metal, that makes IP certificates two things at once: a genuinely useful bootstrap primitive that deletes the self-signed-or-nip.io decision from first-deploy, and a low-stakes rehearsal for the renewal automation the entire PKI will demand soon. The operators who find six-day certs comfortable will find the 45-day default boring. That is exactly the right order to learn it in.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.