For years, web encryption has relied on a basic assumption: if a service wants HTTPS, it needs a domain name. That’s practical—people browse names, not numbers—but also historical: certificate validation and lifecycle management were designed around DNS.
That rule has started to change. As of January 15, 2026, Let’s Encrypt has announced general availability of TLS certificates for IP addresses, a development that makes it possible to secure HTTPS connections directly over IPv4 or IPv6 without relying on a domain. This is particularly relevant for homelabs, temporary infrastructure, test environments, “base” network services, and scenarios where a domain does not fit (or does not exist).
What an “IP Certificate” Means—and Why It Matters Now
A traditional TLS certificate includes domain names in the SAN (Subject Alternative Name) field so that a browser or client can verify that the server it is connecting to is who it claims to be. With this new option, the certificate identifier can be an IP address: the client validates the encrypted channel against that IP, not against an FQDN.
In practice, this solves a very common problem: accessing an HTTPS service by IP—say, an admin console, a temporary panel, a test front-end, or an internal service exposed briefly—without browser warnings, self-signed certificates, or permanent security exceptions.
Let’s Encrypt acknowledges that this will not be “for everyone.” Their own view is that most services will continue to work better with domain-based certificates, due to flexibility (hosting changes, load balancing, multi-site deployments) and usage habits. But for the cases where HTTPS by IP is genuinely needed, general availability removes a barrier that has slowed administrators and developers for years.
The Trade-Off: Ultra-Short 160-Hour Certificates
The key condition for IP certificates is their mandatory short lifetime: 160 hours, a little over six days. Let’s Encrypt chose this approach for a straightforward reason: IP addresses can change hands quickly, especially with residential connections or ephemeral deployments. Keeping a “long-lived” certificate tied to an IP that the requester no longer controls would create avoidable risk.
This aligns with the broader industry trend toward shortening exposure windows in the event of key theft or mis-issuance, and leaning on automation so rotation becomes routine. Let’s Encrypt explicitly positions the 160-hour certificates as part of its strategy to move the ecosystem toward shorter lifecycles.
How Issuance Works: ACME Profiles and Validation Challenges
To obtain IP certificates, Let’s Encrypt requires an ACME client that supports ACME Profiles, and the requester must explicitly select the shortlived profile (the short-lived one). The design prioritizes automation and leaves less room for “manual” setups that tend to be forgotten over time.
There are also sensible technical constraints: you cannot use DNS-01 to prove control of an IP address (there is no DNS record that proves ownership of the address as the primary identifier), so validation is restricted to http-01 and tls-alpn-01. In practical terms, the server must demonstrate real control over the endpoint reachable at that IP to pass the challenge.
Real-World Use Cases: From Homelabs to Critical Infrastructure Services
Let’s Encrypt lists several scenarios where these certificates make sense, and the common pattern is clear: environments where a domain is a luxury, an extra cost, or simply unnecessary for the technical goal.
Typical examples include:
- Secure access to services without a domain, accepting that this is less convenient and more fragile than DNS-based setups.
- Default hosting provider pages—when someone pastes an IP into a browser and the service wants to respond over HTTPS without errors.
- Infrastructure services such as DNS over HTTPS (DoH) or other endpoints where a public certificate helps client validation.
- Remote access to home devices (NAS, IoT, lab equipment) when there is no associated domain.
- Ephemeral connections inside cloud infrastructure, including administration or temporary services—provided there is a public IP available.
The underlying point is that the internet is not only “web pages”: more and more services use HTTPS as a secure transport, even if the end user never sees a friendly name in the browser bar.
Quick Table: What Changes With Short-Lived Certificates
| Certificate type | Identifier | Validity | Profile / approach | Best fit |
|---|---|---|---|---|
| “Classic” certificate | Domain (DNS) | 90 days | Standard automated renewal | Public web, stable services, hybrid infrastructure |
| Planned short-lived (domain) | Domain (DNS) | 45 days | Opt-in and gradual transition | Teams that want more frequent rotation |
| Ultra-short | Domain or IP | 160 hours | shortlived profile (ACME Profiles) | Homelabs, ephemeral environments, direct IP access, testing |
A Note for Sysadmins: Without Automation, This Isn’t Viable
The downside of 160-hour certificates is obvious: renewing every few days is not realistic without a solid automation and monitoring chain. At a minimum, that means:
- scheduled renewals with sufficient margin,
- automated deployment of the new certificate,
- alerts if renewal fails,
- and recurring tests (for example, verifying externally if the endpoint is public).
Let’s Encrypt does not hide that this is the direction it wants the market to move toward. Their roadmap points to progressively reducing the default validity period—from 90 to 45 days—starting with opt-in adoption and supported by ecosystem improvements to make renewal more predictable.
A Small Change on the Surface, With Big Implications
A free, high-volume CA like Let’s Encrypt issuing certificates for IP addresses has impact beyond the novelty. In practice, it normalizes a pattern: encrypt by default even when there is no DNS, using a trust model based on rapid rotation.
For advanced users, the result is immediate: more options to build and expose services without insecure shortcuts. For the broader ecosystem, the message is deeper: the future of TLS looks less like “install a cert and forget it,” and more like “my infrastructure renews certificates the same way it rotates secrets.”
Frequently Asked Questions
What’s the point of a TLS certificate for an IP if I can use dynamic DNS?
It’s useful in environments where you don’t want—or can’t—depend on DNS: labs, testing, ephemeral endpoints, infrastructure services, or direct IP access. With a valid public certificate, clients can verify HTTPS without security exceptions.
Why does Let’s Encrypt cap these certificates at 160 hours?
Because IP “ownership” can change quickly (dynamic IPs, reassignment, temporary infrastructure). A short window reduces the risk of a certificate remaining 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 compatible with ACME Profiles and an explicit request for the shortlived profile. Also, validation cannot be done with DNS-01; you must use methods such as http-01 or tls-alpn-01, depending on the deployment.
How should homelabs or dev environments operate such short-lived certificates?
With full automation: renewals with margin, automated deployment, alerts, and continuous verification. If the process depends on manual steps, expirations and service interruptions become likely.
