Let's Encrypt and most free SSL providers require a domain name — they cannot issue a trusted certificate for a bare IP address. This guide covers your actual options if you need to secure a service accessible only by IP.
Why Standard Free SSL Doesn't Work for IP Addresses
Domain validation (the process Let's Encrypt and similar authorities use to confirm you control what you're requesting a certificate for) is fundamentally built around domain ownership verification — there's no equivalent standard mechanism for proving ownership of a bare IP address in the same way.
Option 1 — Get a Free Domain and Point It to Your VPS (Recommended)
The simplest real fix: obtain any domain (including free/low-cost options from various registrars) and point an A record to your VPS's IP — see How to Point a Domain to Your VPS (A/AAAA Records). Once DNS resolves, standard Let's Encrypt issuance works normally.
Option 2 — Use a Free Dynamic DNS Hostname
Several free dynamic DNS services provide a subdomain (like yourname.example-ddns.net) pointing to your IP, at no cost — this then qualifies for standard domain-validated SSL through Let's Encrypt, since it's technically a real (sub)domain.
Option 3 — Self-Signed Certificate (Internal/Testing Use Only)
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout selfsigned.key -out selfsigned.crtWorks for encryption but triggers a browser warning for every visitor, since it's not issued by a trusted authority — acceptable for internal tools, testing, or service-to-service connections where you control both ends and can manually trust the certificate, but not appropriate for a public-facing service.
Option 4 — Private/Internal Certificate Authority
For internal infrastructure (multiple servers you control, connecting to each other), running your own private CA and distributing its root certificate to trusted clients avoids per-connection browser warnings within your own controlled environment — more setup effort, but appropriate at a larger internal scale.
Option 5 — Commercial IP-Based SSL Certificates (Rare, Specific Use Cases)
A small number of commercial Certificate Authorities historically offered IP-address SSL certificates for specific enterprise use cases, though this is uncommon and not typically necessary given the domain-based alternatives above — if genuinely required, this requires direct consultation with the specific CA.
Which Option Should You Choose?
| Situation | Recommended Option |
|---|---|
| Public-facing production service | Get a real domain (Option 1) — there's no good substitute |
| Quick testing/development | Self-signed certificate (Option 3) |
| Internal tools across your own servers | Free dynamic DNS + Let's Encrypt (Option 2), or a private CA (Option 4) at scale |
Trusting a Self-Signed Certificate for Your Own Tooling
If using a self-signed certificate for internal/testing purposes, you can manually add it to your local machine's trusted certificate store to suppress the browser warning for your own access — this doesn't help other visitors, who would still see the warning.
Common Errors
Certbot fails with a domain validation error when trying to use just an IP — expected behavior; Certbot fundamentally requires a real domain name, not a workaround-able limitation.
FAQ
Is there any way to get a real, trusted certificate for just an IP address?
Not through standard free options like Let's Encrypt; getting a domain (even a low-cost one) pointed at your VPS is by far the most practical path for a public-facing service.
Continue Reading
- How to Point a Domain to Your VPS (A/AAAA Records)
- How to Install Let's Encrypt SSL with Certbot (Nginx & Apache)
- Common SSL Certificate Errors and How to Fix Them
Browse more articles in SSL/TLS & Certificates.
