IP Address Certificates From Let’s Encrypt: Uses and SEO Risks
In this article
An IP address certificate belongs on infrastructure endpoints - admin panels, health checks, origin connections. Not on public websites. If a bare address serves your pages over HTTPS, it can end up as a duplicate host in Google. And this stopped being a theoretical question on January 15, 2026, when Let’s Encrypt announced that short-lived and IP address certificates are generally available, valid for 160 hours. Here is how to decide whether it has a place in your setup.
What Is an IP Address Certificate From Let’s Encrypt?
A TLS certificate that authenticates connections to an IP address instead of a domain name. Let’s Encrypt issues it for both IPv4 and IPv6, and only as one of its short-lived certificates. Why so short? Because addresses change hands far more easily than domain names do, so control over them has to be validated more often.
The idea is old. Certificate standards have always allowed IP identifiers, but only a few certificate authorities offered them, and on a small scale. Let’s Encrypt held off until short lifetimes were in place.
How Do You Request a Let’s Encrypt IP Certificate?
Pick the shortlived profile in an ACME client that supports ACME Profiles, then validate over http-01 or tls-alpn-01. Step by step:
- Check that your client supports the draft ACME Profiles specification.
- Configure it to request the shortlived profile.
- Choose http-01 or tls-alpn-01 as the challenge - the DNS method cannot prove control of an address.
- Automate renewal and alert on failures.
Send an order whose details conflict with these policies and the ACME server rejects it. Retrying won’t help; the client needs an update or a configuration change.
And forget about doing any of this by hand. With a lifetime this short, an expired certificate on an admin endpoint locks out the tools that depend on it.
Where an SSL Certificate for an IP Address Makes Sense
On endpoints you reach by address, not by name - places where no domain exists, or where you simply don’t want DNS as a dependency:
- Admin panels on a fixed IP that only your team opens.
- Health checks and monitoring probes that must keep working when DNS is down.
- Origin connections between a proxy and the backend behind it.
What do you gain over a self-signed certificate? Clients validate the connection normally. No trust exceptions to add, no private certificate authority to babysit. Note that when an NGINX reverse proxy with EU or USA IPs, such as Jalvo, sits in front of existing hosting, the certificate setup still stays on your own origin.
Why Public Websites Should Stay on Their Domain Name
A public site should keep serving under its domain. That is the identifier visitors know and browsers check.
An address changes with every hosting move. A domain doesn’t - it carries links, bookmarks and search history along. So putting a public site on a short-lived IP certificate adds renewal pressure and gives visitors nothing in return. Bad trade, in my view.
The SEO Risk: HTTPS on a Bare IP as a Duplicate Host
Once a bare IP answers over HTTPS with a valid certificate and returns your pages, you have a second host with the same content. Usually by accident. The default NGINX server block handles every request whose Host header matches nothing else, the raw address included, and on many servers that default is the main site.
What you get is a parallel set of URLs that competes with the canonical domain and splits signals between two hosts. Same family of problems as duplicate URLs from slashes, only one level up, at the hostname. Until now, browser warnings on the mismatched certificate limited the exposure, since few people linked to or shared such addresses. A trusted certificate takes that accidental barrier away.
How to Keep IP Hosts Out of Google
Redirect the IP host to the canonical domain with a 301, or block it outright. Which one? Depends on what the address is for.
On a server that hosts a public site, add a dedicated default server block for the address that returns one 301 straight to the https canonical URL. No hops - the same logic applies as when flattening redirect chains on NGINX. Admin panels and health checks are a different story: close the connection for unknown clients or restrict access with an allowlist and authentication, so nothing there is crawlable.
Address-based URLs already indexed? Then the redirect is the cleaner fix, because it moves them to the right host. If you’d rather block, weigh the noindex or disallow choice carefully, since the two behave differently for pages that are already known. Afterwards, send a request to the raw IP and confirm the response is a redirect or a refusal. Never the homepage.
The short version: use an IP address certificate for infrastructure endpoints, keep the public site on its domain, and make sure the address never serves indexable pages.
FAQ
How long is a Let’s Encrypt IP certificate valid?
Only about six days. That policy was set out when Let’s Encrypt described issuing its first IP address certificate. There is no longer-lived variant for addresses.
Can I use the DNS challenge for an IP address certificate?
No. Only the http-01 and tls-alpn-01 methods can prove control of an address.
Will Google index my site under its IP address?
It can, if the address returns your pages over HTTPS. A 301 from the IP host to the canonical domain prevents it. So does a default server block that refuses the connection. Recheck the raw address after every server change.
