For a decade, web encryption has relied on a simple idea: TLS certificates are issued for domain names, not numbers. However, that separation between “what the user writes” (a domain) and “what actually routes Internet traffic” (an IP address) is beginning to lose rigidity. Let’s Encrypt now allows issuing valid certificates for IPv4 and IPv6, a change that opens the door to securing services without relying on DNS and, at the same time, pushes the industry toward a more dynamic trust model based on automation and frequent renewals.
Why this is relevant: when the service lives “directly” on an IP
Let’s Encrypt recognizes that most of its subscribers will continue using certificates for domain names — that’s the norm: users identify services by name, not by IP. But it also admits that there are scenarios where the IP is the practical identifier or, simply, the only available one. Among the scenarios highlighted by the organization:
- Access to a service without a domain, accepting less convenience and reliability compared to DNS.
- Default pages of hosting providers, when someone enters an IP directly into the browser and currently receives a security warning.
- Infrastructure services, such as DNS over HTTPS (DoH), where a publicly trusted certificate facilitates verifying identity and reinforcing policies on clients.
- Remote access to home devices (NAS, IoT) lacking a domain name.
- Ephemeral connections in cloud infrastructures, like backend links or temporary server management, provided a public IP is available.
Practically, this provides a “clean” solution for laboratories, temporary environments, proof-of-concept tests, or deployments that purposefully do not want to depend on DNS to enable HTTPS.
The key condition: certificates must be short-lived
The counterbalance is significant. Let’s Encrypt’s policy requires that certificates including IP addresses be “short-lived”: with a validity of 160 hours (just over six days). This limit is not a trivial detail: it mandates an automated lifecycle from day one.
Additionally, the organization has made generally available (in production) both this IP option and 6-day certificates for domain names, reinforcing the idea that the future of TLS involves faster renewals, shorter exposure windows, and less reliance on “long-lived” certificates.
Operational implications
To issue “short-lived” certificates for IPs, the ACME client must support ACME Profiles and request the corresponding profile (usually, shortlived). In other words: simply having Certbot isn’t enough; it’s necessary to verify that the client and its configuration support profiles.
Another critical restriction: DNS-01 validation cannot be used to prove control over an IP. Let’s Encrypt limits validation to HTTP-01 and TLS-ALPN-01. This makes sense: DNS proves control over a name, not a number.
The bigger context: from 90 to 45 days (and the role of automation)
This move aligns with the strategic direction Let’s Encrypt has been anticipating: a world with less default validity. The certificate authority has outlined plans to reduce the standard validity from 90 days to 45 days, in line with industry trends. Its roadmap cites 2028 as the target for a full transition, along with initiatives to support automated renewals (such as improvements like ARI in the ACME ecosystem).
Put simply: if security used to rely on “issue and forget,” the new model advocates “issue, renew, and constantly verify.” Certificates for IP — by their inherently changing nature and the risk of reassignment — are the most extreme example of this philosophy.
A quick reference table to understand it
| Certificate Type | Identifier | Typical Validity | Supported Validation | Practical Implication |
|---|---|---|---|---|
| Standard TLS | Domain | 90 days | HTTP-01 / DNS-01 / TLS-ALPN-01 (depending on case) | Periodic renewal, automatable |
| Future TLS (roadmap) | Domain | 45 days | Same as standard (depending on CA/client) | More automation, less risk from exposure |
| Short-lived TLS | Domain | 160 hours | Depends on client/profile | Very frequent renewal, aimed at mature automation |
| IP TLS (Let’s Encrypt) | IPv4/IPv6 | 160 hours (mandatory) | HTTP-01 / TLS-ALPN-01 | Ideal for labs/infrastructure; requires automation and endpoint control |
(Profiles and requirements depend on ACME client support and the specific profile configuration.)
Real-world impact: more security but less room for improvisation
From a security perspective, the reasoning is solid: very short certificates mean that if a key leaks or an issuance error occurs, the impact window is drastically reduced. However, operationally, the message is clear: anyone attempting to adopt this without automation — renewal, service reloads, process monitoring — will face avoidable disruptions.
Nevertheless, for sectors experiencing growth in self-hosting, home labs, and ephemeral infrastructures, this move makes sense: HTTPS stops being “synonymous with domain” and becomes “synonymous with verifiable endpoint control,” even if that endpoint is an IP address.
Frequently Asked Questions
What is a TLS certificate for an IP address used for?
To enable HTTPS when accessing a service directly via IPv4/IPv6 (without a domain), or to secure an infrastructure endpoint where a domain is impractical.
Why does Let’s Encrypt limit these certificates to 160 hours?
Because IP addresses can change or be reassigned easily. A very short validity reduces the risk of a certificate remaining active after the IP is no longer under your control, and limits the impact of key leaks.
Can an IP certificate be validated using DNS-01?
No. Let’s Encrypt states that only HTTP-01 and TLS-ALPN-01 are permitted for IP addresses, since DNS proves control of a name, not a number.
What is needed for production use without surprises?
An ACME client supporting ACME Profiles, automated renewal (via cron/systemd), automatic service reloads (Nginx/Apache/HAProxy, etc.), and monitoring of issuance/renewal failures.