For years, web encryption has rested on a basic assumption: if a service wants HTTPS, it needs a domain name. That made sense in practice—people browse names, not numbers—but it also reflected how certificate validation and tooling were built around DNS.
That rule is now starting to change. Let’s Encrypt has announced general availability of TLS certificates for IP addresses, enabling secure HTTPS connections directly to IPv4 or IPv6 addresses without relying on a domain. The move is especially relevant for homelabs, temporary infrastructure, test environments, and “baseline” network services where a domain is inconvenient—or simply not part of the design.
What an “IP certificate” is—and why it matters now
A traditional TLS certificate lists domain names in the SAN (Subject Alternative Name) field so browsers and clients can verify the server’s identity. With IP certificates, the identifier can be an IP address: the client validates the encrypted session against that IP, not an FQDN.
In practical terms, this solves a familiar headache: reaching an HTTPS service by IP—an admin console, a short-lived demo, a staging endpoint, a device UI—without browser warnings, self-signed certificates, or permanent security exceptions.
Let’s Encrypt also makes it clear this won’t replace domain-based certificates for most production services. DNS still provides flexibility (load balancing, migrations, multi-region setups) and aligns with how users access services. But for cases where HTTPS by IP is the right fit, general availability removes a long-standing barrier for admins and developers.
The tradeoff: ultra-short certificates (160 hours)
The big condition is that IP certificates are mandatory short-lived: 160 hours, a little over six days. Let’s Encrypt’s rationale is straightforward: IP addresses can change hands quickly, especially in residential connectivity or ephemeral deployments. A long-lived certificate tied to an IP no longer under the requester’s control would be an avoidable risk.
This aligns with a broader industry direction: shorten the exposure window for stolen keys or issuance mistakes, and rely on automation to make frequent rotation routine. Let’s Encrypt frames the 160-hour option as part of a larger push toward shorter certificate lifetimes.
How issuance works: ACME Profiles and validation challenges
To obtain IP certificates, Let’s Encrypt requires an ACME client that supports ACME Profiles, and you must explicitly request the shortlived profile. The model is built for automation and intentionally discourages “manual” setups that are easy to forget and hard to maintain.
There are also natural validation constraints: you can’t use DNS-01 to prove control of an IP address (there’s no DNS record that establishes “ownership” of the IP as the primary identifier). As a result, validation is limited to http-01 and tls-alpn-01. In practice, the server must prove control of the reachable endpoint on that IP to pass the challenge.
Real-world use cases: from homelabs to infrastructure services
Let’s Encrypt highlights several scenarios where IP certificates make sense, and the common thread is clear: environments where DNS is unnecessary, overhead, or a poor fit for the technical goal.
Typical examples include:
- Securing services without domains, accepting reduced flexibility versus DNS-based setups
- Default landing pages at hosting providers, where users paste an IP into a browser and still expect HTTPS
- Infrastructure endpoints such as DNS over HTTPS (DoH) and other services that benefit from public certificate validation
- Remote access to home devices (NAS, lab gear, IoT) when there is no associated domain
- Ephemeral cloud infrastructure, including short-lived admin or test services, where a public IP exists
The broader signal is that the “web” is not only websites: more services use HTTPS as a secure transport layer even when a user never sees a friendly domain name.
Quick table: what changes with short-lived certificates
| Certificate type | Identifier | Validity | Profile / model | Best fit |
|---|---|---|---|---|
| “Standard” certificate | Domain (DNS) | 90 days | Default automated renewal | Public web, stable services, hybrid infra |
| Planned short-lived (transition) | Domain (DNS) | 45 days | Opt-in as the ecosystem adapts | Teams that want tighter rotation cycles |
| Ultra-short | Domain or IP | 160 hours | shortlived profile (ACME Profiles) | Homelabs, ephemeral endpoints, direct IP access |
A practical warning for operators: without automation, it won’t work
The downside of 160-hour certificates is obvious: renewing every few days is not realistic without solid automation and monitoring. At a minimum, that means:
- scheduled renewals with buffer time
- automated deployment of the new certificate
- alerting on renewal failures
- periodic external checks (especially if the endpoint is public)
Let’s Encrypt does not hide the direction of travel: the plan is to reduce typical lifetimes over time—moving from 90 days to 45 days, starting with opt-in adoption and ecosystem improvements to make renewal more predictable at scale.
A small-sounding change with outsized implications
Issuing IP certificates at Let’s Encrypt’s scale is more than a convenience feature. It normalizes a pattern: encrypt by default even when DNS isn’t in the picture, using fast rotation as a security control.
For advanced users, the value is immediate: fewer insecure workarounds when building and exposing services. For the broader ecosystem, the message is deeper: TLS is moving away from “install it and forget it” and toward “rotate certificates the way you rotate secrets.”
FAQs
What’s the point of a TLS certificate for an IP if I can use dynamic DNS?
It’s for cases where you don’t want—or can’t rely on—DNS: labs, tests, ephemeral endpoints, infrastructure services, or direct IP workflows. A publicly trusted certificate avoids browser warnings and security exceptions.
Why does Let’s Encrypt cap IP certificates at 160 hours?
Because IP “ownership” can shift quickly (dynamic assignments, reallocation, ephemeral infra). A short lifetime reduces the risk of a certificate staying valid after the requester no longer controls that IP.
What do I need to issue an IP certificate with Let’s Encrypt?
An ACME client that supports ACME Profiles, and you must request the shortlived profile. Validation uses http-01 or tls-alpn-01 (not DNS-01).
How should I operate these in homelabs or dev environments?
With full automation: frequent renewal with buffer time, automatic deployment, alerting, and routine verification. If renewal is manual, expirations—and downtime—are likely.