Can You Get an SSL Certificate for an IP Address? Yes, With One Catch

You can. Publicly trusted certificates for IP addresses have always been technically permitted, a handful of commercial certificate authorities have sold them for years, and since January 2026 Let's Encrypt has issued them free. The catch is the lifetime: an IP certificate from Let's Encrypt is valid for 160 hours, just over six days, and that constraint is deliberate rather than temporary.

This article covers why IP certificates were rare for so long, what changed, the six day rule and the reasoning behind it, the practical requirements for getting one, and the question worth asking before you do, which is whether a domain name would serve you better.

Why these were rare, not impossible

The standards have always allowed it. An X.509 certificate lists the identities it covers in the Subject Alternative Name field, and that field supports an iPAddress type alongside the more familiar DNS name type. Let's Encrypt's own explanation of its first IP certificate makes the point directly: there is no reason in principle a certificate could not be issued for an IP rather than a domain, and the technical and policy standards have always allowed it, with a small number of authorities offering the service at limited scale.

So the scarcity was a market and policy choice rather than a technical barrier. A few commercial CAs including Sectigo, GeoTrust, and PositiveSSL have sold IP certificates for years at prices in the region of forty to ninety dollars annually. Most did not bother, because demand was thin. Users reach services by name, and an IP address in a browser bar is an unusual thing to hand to a customer.

There was also a real objection underneath the commercial one. IP addresses are far more transient than domain names. A site can move between hosting providers, update its DNS, and keep the same name while every underlying address changes. Addresses get reassigned, released back to pools, and handed to someone else. A certificate that certifies control of an address at a moment in time becomes wrong faster than one certifying a domain, and it becomes wrong without anyone doing anything visible.

What changed, and the six day rule

Let's Encrypt issued its first IP address certificate on 1 July 2025 and made them generally available on 15 January 2026, alongside short-lived certificates. Both IPv4 and IPv6 are supported.

The condition attached is that IP certificates must be short-lived. Nothing about the handshake itself changes, and our explainer on how SSL works covers the step where the client matches the identity it asked for against the one the certificate carries. What changes is the clock: IP certificates are issued only under the shortlived profile, which has a validity of 160 hours, or just over six days. Let's Encrypt states the reasoning explicitly: IP addresses are more transient than domain names, so validating more frequently is important. That is the six day rule, and it is not a limitation that will be relaxed once the feature matures, because the transience it addresses is a permanent property of IP addresses.

Six days changes what this is for. A certificate that must be replaced roughly weekly is not something you install by hand, so an IP certificate is only realistic with working automation. Certbot supports the workflow through the preferred-profile flag introduced in Certbot 4.0 and an ip-address flag added in Certbot 5.3, which together let you request one. Any ACME client you use needs to support ACME profiles, which rules out older tooling.

What you need in order to get one

Three requirements, and the first eliminates most casual interest.

The address has to be publicly reachable, because validation works by proving control over the address itself. That means a public IP, not an RFC 1918 private range address like 192.168.1.10 or 10.0.0.5. No public CA can validate control of an address inside your network, which means the homelab case that motivates many of these searches is not solved by a public IP certificate. For internal addresses, an internal certificate authority remains the answer.

You need control of the address at validation time, and you need to keep it. A dynamic address from a residential ISP technically works at the moment of issuance and stops being yours without warning, which is precisely the scenario the six day lifetime is designed to bound. Static addressing is effectively a prerequisite for this being worth doing.

And you need automation that runs on a six day cycle with margin. A weekly cron job is not enough headroom, because a single failed run leaves you with no valid certificate. Renewal should attempt well before expiry and alert on failure, which for a 160 hour certificate means checking daily rather than weekly.

Whether you actually want one

The honest answer for most people is no, and it is worth saying why before you build the automation.

A domain name is cheap, and once you have one, a standard certificate lasts 200 days rather than six, uses ordinary validation, works with every ACME client, and survives a change of hosting provider without touching the certificate at all. If your service will be used by people who type an address, a name is better in every dimension including the one that matters most, which is that the address behind the name can change freely.

The cases where an IP certificate genuinely fits are narrower and mostly infrastructural: securing connections between backend services that address each other numerically, ephemeral endpoints that will not live long enough to justify DNS, network appliances and management interfaces reached by address, and test infrastructure where creating DNS records is more friction than it is worth. In those cases the six day lifetime is not a burden, because the thing being secured is often shorter-lived than the certificate.

Whichever route you take, the operational reality is the same and it is stricter here than anywhere else. A six day certificate that fails to renew produces a browser warning within a week, and browsers do not care why. Checking what a host is actually presenting, rather than what your automation reported, is the only way to know the chain is holding, which is what our guide to SSL checkers covers in detail.

Common mistakes in using IP address certificates

Trying to get one for a private address. Public CAs cannot validate control of an RFC 1918 address. A homelab on 192.168.1.x needs an internal CA, not Let's Encrypt.

Assuming the six day lifetime is temporary. It reflects a permanent property of IP addresses, which is that they change hands faster than names. Plan the automation around it rather than waiting for it to be relaxed.

Using an old ACME client. IP certificates require ACME profiles support. Certbot needs the preferred-profile flag from 4.0 and the ip-address flag from 5.3, and other clients need their own equivalents.

Renewing weekly for a 160 hour certificate. That leaves no margin at all. One failed run and the certificate expires. Attempt renewal daily and alert loudly on failure.

Reaching for an IP certificate when a domain would do. A name costs a few dollars a year, gets a 200 day certificate, and lets the underlying address change without touching anything. Most requests for an IP certificate are better served by a hostname.

FAQ

Can you get an SSL certificate for an IP address?

Yes. The standards have always allowed IP addresses in the Subject Alternative Name field, several commercial CAs have sold them for years, and Let's Encrypt has offered them free and generally available since 15 January 2026 for both IPv4 and IPv6.

How long does an IP address certificate last?

From Let's Encrypt, 160 hours, which is just over six days. They are issued only under the shortlived profile because IP addresses change hands more often than domain names, so more frequent validation is required.

Can I get a certificate for a private IP like 192.168.1.1?

No. A public certificate authority cannot validate control of an address inside a private network. Internal addresses need a certificate from a private or internal CA, which your systems then have to trust.

Should I use an IP certificate instead of a domain name?

Usually not. A domain gives you a certificate lasting 200 days, standard validation, and the freedom to change the underlying address without reissuing. IP certificates fit backend, ephemeral, and appliance cases where no name exists or is warranted.

Closing thought

This is one of those questions where the answer flipped recently enough that most of the advice online is still wrong. For years the correct response was that you basically could not get one, and that answer stopped being true in January 2026. What has not changed is the reasoning underneath: addresses are less stable identities than names, and the six day lifetime is that instability written into policy. Treat the short lifetime as the feature it is, and only reach for this when there genuinely is no name to use.

If you are running certificates on a cycle this short, knowing what a host is actually serving matters more than knowing what your renewal job reported. Odown provides unlimited SSL monitors on every plan, checks each on a daily cycle, and alerts at 30, 10, and 7 days before expiry with custom thresholds you will want to tighten considerably for anything measured in hours rather than months.