IP address SSL certificate: what now works

Published 23 September 2026

You can get a publicly trusted SSL certificate for a public IPv4 or IPv6 address. Let's Encrypt made IP address certificates generally available in January 2026, and current Certbot releases can request them. They last only 160 hours (just over six days)so this is an automation feature, not a new way to manage certificates by hand.

The line between public and private

Address	Public CA certificate?	Use instead if not
Public IPv4 or IPv6 you control	Yes, after control validation	—
RFC 1918 private IPv4 such as 10.0.0.8	No	Private CA or an internal DNS name
Loopback, link-local or reserved address	No	Local development certificate or private CA
Cloud address that may be reassigned	Technically possible while controlled	Prefer a stable DNS name unless the IP identity is the point

The CA/Browser Forum rules prohibit public certificate authorities from issuing for reserved IP addresses. A public CA also cannot prove control of 192.168.1.20 from the public Internet. Nothing about the 2026 change turns private addressing into a public identity system.

The address is encoded in the certificate's Subject Alternative Name as an iPAddress, not as text in a DNS-name field. That distinction is old (RFC 5280 has specified it since 2008)but broad, automated public issuance is the new part.

Why the certificate lasts six days

IP addresses are reassigned more readily than domain names. A cloud address can return to a provider's pool; an ISP allocation can change; an anycast address can be announced by a different operator. Let's Encrypt therefore requires its IP certificates to use the short-lived profile. The validity period is 160 hours.

Short life reduces the period in which a previously valid certificate can outlive control of the address. It also makes failed renewal unforgiving. A 90-day certificate commonly renews around day 60, leaving weeks to notice a broken job. A six-day certificate needs monitoring measured in hours. The wider TLS certificate lifetime schedule now caps newly issued public certificates at 200 days and reaches 47 days in 2029.

The certificate is not a substitute for address ownership. If the IP can move away from you, the service identity can move too. The short lifetime limits that risk; it does not make a transient address stable.

Which ACME challenges work

Let's Encrypt can validate an IP address with HTTP-01 on port 80 or TLS-ALPN-01 on port 443. DNS-01 cannot validate an IP address because there is no applicant-controlled DNS name on which to place the challenge record.

HTTP-01 is the practical default. The CA retrieves a challenge file from the address on port 80.
TLS-ALPN-01 works entirely at the TLS layer, but client support is narrower and it is mainly useful to hosting platforms and reverse proxies.
DNS-01 works for domain identifiers and wildcards, not for an IP identifier.

Firewalls, NAT and load balancers still matter. The validation request must reach the system serving the challenge for the public address. Opening port 80 on an internal server does not help if a different edge device owns the address.

Request one with Certbot

Let's Encrypt's March 2026 instructions use current Certbot with the shortlived ACME profile and the --ip-address option. Start against staging so a typo does not consume production issuance attempts:

sudo certbot certonly --staging \
  --preferred-profile shortlived \
  --webroot \
  --webroot-path /var/www/html \
  --ip-address <PUBLIC_IP>

Once staging succeeds, remove --staging. Certbot can obtain the certificate, but its current IP-certificate support does not automatically install it into every web server. Point the server at the generated fullchain.pem and privkey.pem, then reload it safely after renewal.

A Certbot IP address certificate is an ordinary X.509 certificate with an IP SAN; the unusual parts are how control is validated and how quickly it expires. The web server still loads it the same way it loads a certificate for a DNS name.

A renewal job is incomplete until four things have happened: a new certificate was issued, the service received it, the service reloaded it, and an outside client observed the new certificate. Monitoring only the ACME client's exit code misses half the path.

Verify the installed certificate

openssl s_client -connect <PUBLIC_IP>:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -ext subjectAltName

Look for the exact address as an IP Address entry in the SAN, then check notAfter. Do not accept a matching common name as a replacement for the IP SAN. Modern identity checks use the SAN.

Also inspect the chain from outside the host. A certificate can contain the right address and still fail because the server omitted an intermediate; unable to get local issuer certificate explains that separate failure. The Kodura SSL checker accepts public targets and reports the chain the server actually sends.

When an IP certificate is the right answer

An HTTPS API is deliberately addressed by a stable public IP and adding a DNS dependency would defeat the use case.
A monitoring or bootstrap endpoint must authenticate before normal DNS service is available.
An appliance or edge endpoint has a public address as its intended identity and already has reliable ACME automation.

It is usually the wrong answer for an ordinary website, a Kubernetes service, a cloud VM with an ephemeral address, or anything on a private LAN. A domain is portable between addresses, works naturally with virtual hosting, and gives people a usable service name. The fact that an IP certificate is possible does not make DNS obsolete.

Failure modes worth alerting on

Symptom	Likely cause	Check
HTTP-01 timeout	Port 80 blocked or routed elsewhere	Fetch the challenge through the public IP from outside
Certificate issued but old one still served	Wrong file path or no reload	Compare the live serial and expiry after deployment
Name mismatch	Address encoded incorrectly or another virtual host answered	Inspect SAN type and the default TLS listener
Renewal suddenly rejected	Address control or routing changed	Confirm the allocation and both validation paths
Works locally, fails remotely	Split routing, NAT or an edge terminator presents another certificate	Capture what the public listener actually serves

Do not respond by disabling certificate verification. That converts a precise identity failure into an encrypted connection to an unknown peer. The same warning applies when diagnosing ERR_CERT_AUTHORITY_INVALID: fix the identity or trust path rather than deleting the check.

Sources

6-day and IP Address Certificates are Generally Available: Let's Encrypt, 15 January 2026
Six-Day and IP Address Certificates Available in Certbot: request syntax and current installation limitation
Challenge Types: Let's Encrypt, IP support for HTTP-01 and TLS-ALPN-01
RFC 5280 section 4.2.1.6: encoding IPv4 and IPv6 identities in Subject Alternative Name
CA/Browser Forum Baseline Requirements: prohibition on reserved addresses and current validation rules

Client support and ACME tooling are changing quickly. The commands and limitations here were checked against Let's Encrypt and Certbot guidance in September 2026.