SSL Certificate for an IP Address: What You Can and Cannot Get

Can you get an SSL certificate for an IP address?

Yes, for a public address you can prove control of. The Baseline Requirements have allowed IP addresses in publicly trusted TLS certificates for years, and the CA/Browser Forum maintains dedicated guidance on how they must be encoded and validated. Two ceilings apply that do not apply to hostnames: the address has to be globally routable, and the certificate can be DV or OV but never EV.

What surprises people is how ordinary the resulting certificate is. It is the same X.509 object, in the same PEM or PFX file, loaded by nginx or IIS with the same two configuration lines. The only structural difference sits in one extension: instead of a dNSName entry reading api.example.com, the subject alternative name holds an iPAddress entry containing four bytes for IPv4 or sixteen for IPv6. RFC 5280 defines that encoding, and clients compare the address they dialled against it directly.

The practical question is rarely whether it is possible. It is whether the address in your hand is the kind that qualifies, which is where most of these projects stop.

Which IP addresses qualify, and which never will

Only public, globally routable addresses qualify. Anything in a reserved range is permanently out of reach of every publicly trusted CA, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, the loopback address 127.0.0.1, and the IPv6 unique local range fc00::/7. This is not a product gap that a larger order fixes. Issuance for reserved addresses and internal names stopped in 2015, and any certificates of that kind still in circulation were revoked by 1 October 2016.

The reasoning holds up well. A reserved address is not unique: 192.168.1.10 exists on millions of separate networks simultaneously. A certificate naming it would be equally valid on every one of them, so anyone who obtained a copy could present it on any network they reached. The public trust system has no way to say which 192.168.1.10 you meant, so it refuses to guess.

How do you prove control of an IP address?

By answering a challenge on the address itself, in almost every case. Section 3.2.2.5 of the Baseline Requirements lists the permitted methods, and the survivors are the automated ones: serving a file over HTTP on port 80, or answering a TLS-ALPN challenge on port 443, at that exact address. Registry-based proof through the contact listed for the IP block still exists on paper, and it is being retired.

Two ballots reshaped this recently. Ballot SC-090 sets 15 March 2027 as the sunset date for method 3.2.2.5.2, which contacts the registry-listed owner by email, fax, SMS or post, and for method 3.2.2.5.5, the phone-call equivalent. Ballot SC-091 retires method 3.2.2.5.3, reverse address lookup, and introduces a DNS-based method built on a persistent value in a TXT record instead.

Read together, those two changes point at one requirement: a machine that can answer for itself. If the address belongs to a device that cannot serve anything on port 80 or 443, or sits behind a load balancer that terminates the challenge somewhere else, the validation is the hard part of the project rather than the paperwork.

How long does an IP address certificate last?

A commercial IP certificate follows the same ceiling as every other publicly trusted TLS certificate: at most 200 days since 15 March 2026 under ballot SC-081v3, with CAs issuing at 199 days to stay inside it. A free one from Let's Encrypt lasts 160 hours, a little under seven days, because addresses are only offered on the shortlived profile. The two numbers describe completely different operational realities.

The ceiling keeps falling on a published schedule, and validation data reuse falls with it. From 15 March 2027 certificates cap at 100 days and reuse at 100 days; from 15 March 2029 the figures are 47 days and 10 days. The reuse number is the one that changes daily work, because it decides how often you re-prove the address rather than how often you install a file.

Our breakdown of the 199-day certificate works through the same schedule for hostname certificates, and the automation advice transfers directly. Nothing about an address makes renewal easier, and the shorter free option makes it mandatory.

Let's Encrypt or a commercial CA?

Pick on renewal capability rather than price. Let's Encrypt has issued IP address certificates to the general public since 15 January 2026, at no cost, on the condition that you use the shortlived profile and renew roughly every six days. A commercial CA charges for the certificate and hands back up to 199 days, which is what makes it viable on a device nobody automates.

The free route has a client requirement worth checking before you plan around it. Requesting an address certificate needs an ACME client that supports profile selection. Certbot added the --preferred-profile flag in version 4.0, the --ip-address flag in 5.3, and webroot support for addresses in 5.4. Certbot obtains these certificates but does not yet install them into a web server for you, so the deployment step stays yours.

That last row is worth pricing carefully. Multi-domain certificates carry several names in one file, and where a CA permits address entries they sit in the same SAN list as the hostnames. Certum, the authority behind My-SSL certificates, runs a dedicated IP SSL product for public IPv4 addresses, so confirm the exact product and address family with us before you commit a deployment to it.

How to request one, step by step

The order differs from a normal certificate in exactly one place: the address goes in the SAN list as an iPAddress entry. Generate the key and CSR the way you always do, name the address instead of a hostname, then pass whichever validation challenge the CA offers on that address. Everything after issuance is identical to a hostname certificate.

1. Confirm the address is public. Check it against the reserved ranges before anything else. A NAT address that looks public from inside your network is the most common false start.
2. Confirm you can answer on it. Port 80 or port 443 has to reach the machine you are validating from, at the address itself, without a redirect to a hostname.
3. Generate the CSR with an IP SAN. With OpenSSL, add subjectAltName = IP:203.0.113.10 to the request configuration. The value has to be an IP entry; writing it as a DNS entry produces a certificate no client will match.
4. Order at DV or OV. OV adds organisation vetting on top of the address check, so allow the usual business-day turnaround for document review rather than expecting instant issuance.
5. Install and verify from outside. Connect to the address from a network you do not control and confirm the presented certificate matches. A local test can succeed against a cached chain that a stranger will never see.
6. Automate the renewal on day one. With a 200-day ceiling falling to 100 in 2027, and six days on the free path, this is the step that decides whether the deployment survives the year.

For the free path the whole sequence collapses into one Certbot invocation with --ip-address and --preferred-profile shortlived, on Certbot 5.3 or later. Our Certbot and ACME automation guide covers the renewal hooks and failure handling that a six-day lifetime demands.

What breaks, and where to look first

Four failures account for most IP certificate tickets, and three of them are visible before you order. The distinctive symptom is a certificate that validates in one place and fails in another, which almost always traces back to how the address was encoded rather than to the CA.

The encoding problem is the one worth testing for directly, because a CA portal will happily display the address in both fields and give no hint which one the client will use. Connect to the endpoint and read what it presents. Our SSL checker reports the SAN list as served, which is the only version that decides whether a connection validates.

When you should use a hostname instead

Use a hostname whenever you can point one at the service. A hostname certificate costs less, works at every validation level including EV, moves with the service when the address changes, and can be validated by DNS record on a machine that answers nothing on port 80. An address certificate gives up all four properties in exchange for working when no name exists.

The exceptions are real and reasonably narrow. Appliances shipped to customers who will never configure DNS, bare cloud instances reached by address during provisioning, internal APIs called by address for latency reasons, and infrastructure where the address is the identity rather than a location. If your situation is not one of those, a subdomain of a domain you already own solves the problem for less money and less operational risk.

One caution about permanence, since it is the part that bites later. An address is leased from a provider and can be withdrawn on their schedule, which turns a working TLS configuration into a reissue. A name you own is yours for as long as you renew it. Working out which certificate you need walks the same decision for the rest of your estate.

Frequently asked questions