How to Get a Let’s Encrypt Certificate for an IP Address: A Detailed Technical Guide

When it comes to securing web traffic, Let’s Encrypt has become the go-to choice for free, automated, and trusted SSL/TLS certificates. Most administrators are familiar with obtaining certificates for domain names, but what if you want to secure a service running directly on an IP address rather than a domain?

This is a tricky subject because Let’s Encrypt is designed to issue certificates only for domain names (FQDNs) under the control of the requester. However, in certain scenarios—such as internal tools, testing servers, or services bound to public IPs—you may want SSL encryption without buying a custom domain.

In this article, we’ll walk through what’s possible, what isn’t, and the technical workarounds for using Let’s Encrypt certificates with IP addresses.

Why SSL/TLS Certificates Don’t Usually Work with IPs

Before diving into the how-to, let’s understand the limitations. SSL/TLS certificates rely on a Subject Alternative Name (SAN) field to validate identities. Typically, these SANs are domain names like example.com or api.example.org.

The challenge with IP addresses is:

1. Let’s Encrypt Policy – Let’s Encrypt does not issue certificates for bare IP addresses like 203.0.113.10. Their ACME protocol requires proof of control over a domain.
2. Trust Issues – Browsers and operating systems generally expect certificates to be tied to domains. While the X.509 standard technically supports IP addresses in SANs, very few Certificate Authorities (CAs), including Let’s Encrypt, issue them publicly.
3. Renewal Automation – Without DNS validation, automation becomes difficult, as Let’s Encrypt relies heavily on DNS-01 or HTTP-01 challenges tied to domain names.

That said, there are workarounds and alternatives you can use to secure services running on IPs.

Option 1: The Recommended Approach – Use a Free Domain with Let’s Encrypt

The most reliable solution is to map your server’s IP address to a free or low-cost domain and then use Let’s Encrypt as usual.

Step 1: Register a Domain

You can register a domain from providers like:

• Freenom (free domains like .tk, .ml, .ga)
• Paid providers (Namecheap, Google Domains, Cloudflare Registrar, etc.)

Step 2: Point the Domain to Your IP

• Log into your domain registrar’s DNS management console.
• Create an A record pointing to your server’s public IPv4 address, e.g.:A myserver.example.com 203.0.113.10
• If using IPv6, create an AAAA record:AAAA myserver.example.com 2001:db8::1

Step 3: Install Certbot

On a Linux server (e.g., Ubuntu/Debian):

sudo apt update
sudo apt install certbot python3-certbot-nginx

For Apache:

sudo apt install certbot python3-certbot-apache

Step 4: Request a Certificate

Run Certbot with your domain:

sudo certbot --nginx -d myserver.example.com

This configures SSL automatically. For Apache:

sudo certbot --apache -d myserver.example.com

Step 5: Test Auto-Renewal

Certificates from Let’s Encrypt are valid for 90 days, but Certbot can auto-renew. Test renewal with:

sudo certbot renew --dry-run

👉 This method allows you to securely connect using your domain, while still serving traffic from your server’s IP.

Option 2: Self-Signed Certificates for Pure IP Usage

If you absolutely must use the raw IP address in the browser (e.g., https://203.0.113.10), you’ll need to fall back to a self-signed certificate. While not trusted by default, you can manually add it to your system or browser trust store.

Generate a Self-Signed Certificate with OpenSSL

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout ip.key -out ip.crt \
  -subj "/CN=203.0.113.10"

This creates:

• ip.key → Private key
• ip.crt → Self-signed certificate

Install in Nginx

server {
    listen 443 ssl;
    server_name 203.0.113.10;

    ssl_certificate     /etc/nginx/ssl/ip.crt;
    ssl_certificate_key /etc/nginx/ssl/ip.key;

    location / {
        root /var/www/html;
    }
}

Reload Nginx:

sudo nginx -s reload

👉 Downside: Browsers will show a warning (“Not Secure”) unless you manually import the certificate.

Option 3: Use a Reverse Proxy with Domain-Based TLS

Another trick is to use a reverse proxy such as Nginx or Traefik that terminates TLS for a domain and forwards traffic to your IP service.

For example:

• Public-facing domain → Secured by Let’s Encrypt via proxy
• Backend service → Runs on raw IP internally

This way, clients access the secure domain, but your internal service can still run on IP.

Example with Traefik

Traefik can automatically handle Let’s Encrypt with DNS-01 or HTTP-01 challenges. In traefik.toml:

[entryPoints]
  [entryPoints.websecure]
    address = ":443"

[certificatesResolvers.myresolver.acme]
  email = "[email protected]"
  storage = "acme.json"
  [certificatesResolvers.myresolver.acme.httpChallenge]
    entryPoint = "web"

Then map your service under the secured domain.

Option 4: Alternatives to Let’s Encrypt for IP Certificates

While Let’s Encrypt doesn’t support IP SANs, a few commercial certificate authorities do issue them, typically for enterprise use cases. For example:

• DigiCert
• GlobalSign
• Entrust

These often come at a cost and may require proof of IP ownership (e.g., via WHOIS).

Common Mistakes to Avoid

1. Expecting Let’s Encrypt to Support IPs – It won’t. Always plan with a domain.
2. Forgetting DNS Propagation – After pointing a domain to an IP, allow DNS to propagate (usually a few minutes to hours).
3. Skipping Auto-Renewal Setup – Certificates expire every 90 days; missing renewal will cause downtime.
4. Testing with Wrong CN/SAN – Ensure your certificate’s SAN matches either your domain or IP (in self-signed cases).

Security Best Practices

• Always redirect HTTP to HTTPS using 301 redirects in Nginx or Apache.
• Enable strong ciphers and TLS 1.2/1.3 only.
• Use HSTS (HTTP Strict Transport Security) to enforce HTTPS.
• Monitor renewal logs (/var/log/letsencrypt/letsencrypt.log).
• Deploy a firewall to block unnecessary ports.

Conclusion

Getting a Let’s Encrypt certificate for a bare IP address is not possible due to CA restrictions. The best approach is to register a domain, point it to your server’s IP, and obtain a free certificate via Certbot.

For scenarios where you can’t use a domain, you’ll need to either:

• Use a self-signed certificate and manage trust manually, or
• Invest in a paid CA certificate that supports IP SANs.

For most use cases, the domain-based method is the simplest, most secure, and future-proof approach. With proper setup, you’ll have a fully automated, free, and trusted SSL/TLS solution securing your server—whether it’s a website, an API, or an internal service.