<\/i> Why IP-Based SSL is a DevOps Essential<\/h2>\n
The need for encrypted traffic isn’t limited to public-facing websites with pretty domain names. Modern infrastructure relies heavily on secure, machine-to-machine communication where a domain name is an unnecessary abstraction. Think about:<\/p>\n
- \n
- API Gateway Security:<\/strong> Securing backend APIs accessed directly by IP during development or within a private network segment.<\/li>\n
- Staging & Testing Environments:<\/strong> Configuring HTTPS for pre-production servers before DNS records are pointed to them.<\/li>\n
- IoT & Embedded Systems:<\/strong> Devices or appliances that have a public IP but no associated domain name require encryption for management interfaces.<\/li>\n
- Ephemeral Infrastructure:<\/strong> Containers or temporary cloud instances spun up for a specific task that need immediate, trusted SSL.<\/li>\n<\/ul>\n
Historically, securing an IP required expensive, manually-issued certificates. The introduction of Let’s Encrypt’s IP certificate capability changed everything, but with a crucial caveat: 6-day validity periods.<\/strong> This isn’t a limitation\u2014it’s a design feature for automation-first security, perfectly aligning with Infrastructure-as-Code (IaC) principles.<\/p>\n
\nThe UnderHost Infrastructure Advantage<\/h3>\n
When you run this setup on an UnderHost Cloud VPS<\/a> or Dedicated Server<\/a>, you’re building on a foundation of 10Gbps connectivity, enterprise-grade DDoS protection, and 99.9% uptime. Our global network ensures the HTTP-01 validation challenge\u2014essential for IP certificates\u2014is fast and reliable, removing a common point of failure.<\/p>\n<\/div>\n
<\/i> The Non-Negotiable Prerequisites<\/h2>\n
Success with IP-based SSL hinges on meeting specific server and network conditions. Let’s validate your environment.<\/p>\n
\n<\/i> Mandatory Checklist<\/h3>\n
- \n
- ✅ Public, Routable IP:<\/strong> The IP must be publicly accessible on the internet. NAT, private IPs (like 10.x.x.x, 192.168.x.x), or cloud provider internal IPs will not work.<\/strong> Verify with:
\ncurl -4 ifconfig.me<\/code><\/li>\n- ✅ Open Ports 80 & 443:<\/strong> Let’s Encrypt must validate your control over the IP via HTTP on port 80. Ensure your firewall (e.g.,
ufw<\/code>,firewalld<\/code>,iptables<\/code>) allows inbound connections on these ports.<\/li>\n- ✅ No Proxy\/CDN in Front:<\/strong> The validation request must hit your server directly. If you use Cloudflare (in proxy mode) or another CDN that terminates SSL before your IP, it will block validation.<\/li>\n
- ✅ Root or Sudo SSH Access:<\/strong> You need elevated privileges to install packages, stop\/start the web server, and modify its configuration.<\/li>\n
- ✅ Compatible OS:<\/strong> Ubuntu 20.04+, Debian 11+, AlmaLinux 8+, Rocky Linux 8+.<\/li>\n<\/ul>\n<\/div>\n
<\/i> Step-by-Step: Installation & Configuration via SSH<\/h2>\n
This is a hands-on walkthrough. Connect to your server via SSH and follow each step.<\/p>\n
Step 1: Install Certbot<\/h3>\n
The tool of choice is Certbot, the official Let’s Encrypt client.<\/p>\n
For Ubuntu\/Debian:<\/strong><\/p>\n
\r\n
sudo apt update && sudo apt install -y certbot<\/code><\/pre>\nFor AlmaLinux\/Rocky:<\/strong><\/p>\n
\r\n
sudo dnf install -y epel-release\r\nsudo dnf install -y certbot<\/code><\/pre>\nStep 2: Temporarily Free Port 80<\/h3>\n
Certbot’s “standalone” mode for IP validation needs to bind to port 80. You must stop your web server for a few seconds.<\/p>\n
\r\n
# For Nginx:\r\nsudo systemctl stop nginx\r\n\r\n# For Apache:\r\nsudo systemctl stop apache2 # or httpd on some systems<\/code><\/pre>\nStep 3: Request the Certificate<\/h3>\n
Replace
YOUR_PUBLIC_IP<\/code> with your actual IP address. For an IPv6 address, use it directly without brackets in this command.<\/p>\n\r\n
sudo certbot certonly --standalone \\\r\n --preferred-challenges http \\\r\n --agree-tos \\\r\n --register-unsafely-without-email \\\r\n -d YOUR_PUBLIC_IP<\/code><\/pre>\nIf successful, you’ll see a confirmation with the certificate paths. They will be in
\/etc\/letsencrypt\/live\/YOUR_PUBLIC_IP\/<\/code>.<\/p>\nStep 4: Configure Your Web Server<\/h3>\n
Now, point your web server to the new certificate files. Restart your web server first:<\/strong>
sudo systemctl start nginx<\/code> (orapache2<\/code>).<\/p>\nNginx Configuration Snippet:<\/strong> Add this to your server block (e.g., in
\/etc\/nginx\/sites-available\/default<\/code> or a new file in\/etc\/nginx\/conf.d\/<\/code>).<\/p>\n\r\n
server {\r\n listen 443 ssl;\r\n server_name YOUR_PUBLIC_IP; # Use your actual IP\r\n\r\n ssl_certificate \/etc\/letsencrypt\/live\/YOUR_PUBLIC_IP\/fullchain.pem;\r\n ssl_certificate_key \/etc\/letsencrypt\/live\/YOUR_PUBLIC_IP\/privkey.pem;\r\n\r\n # ... your root, index, and other directives ...\r\n}<\/code><\/pre>\nApache Configuration Snippet:<\/strong> Ensure the SSL module is enabled (
sudo a2enmod ssl<\/code>), then configure a virtual host.<\/p>\n\r\n
<VirtualHost *:443>\r\n ServerName YOUR_PUBLIC_IP\r\n SSLEngine on\r\n SSLCertificateFile \/etc\/letsencrypt\/live\/YOUR_PUBLIC_IP\/fullchain.pem\r\n SSLCertificateKeyFile \/etc\/letsencrypt\/live\/YOUR_PUBLIC_IP\/privkey.pem\r\n # ... your DocumentRoot and other directives ...\r\n<\/VirtualHost><\/code><\/pre>\nAfter editing, test your config (
sudo nginx -t<\/code> orsudo apachectl configtest<\/code>) and reload (sudo systemctl reload nginx<\/code> orapache2<\/code>).<\/p>\nStep 5: Test the SSL Connection<\/h3>\n
\r\n
curl -vI https:\/\/YOUR_PUBLIC_IP<\/code><\/pre>\nYou should see the SSL handshake succeed. You can also visit
https:\/\/YOUR_PUBLIC_IP<\/code> in a browser (you’ll likely get a privacy warning because the IP is not a domain, but you can view the certificate details).<\/p>\n<\/i> The Critical Step: Automating Renewal (6-Day Certs)<\/h2>\n
This is not optional. Let’s Encrypt IP certificates expire in 6 days<\/strong>. Manual renewal is unsustainable. The solution is a cron job that renews daily.<\/p>\n
First, create a renewal script that safely stops the web server, runs the renewal, and starts it again. The
certbot renew<\/code> command only renews certificates that are near expiry.<\/p>\n\r\n
sudo nano \/usr\/local\/bin\/le-ip-renew.sh<\/code><\/pre>\nPaste the following script:<\/p>\n
\r\n
#!\/bin\/bash\r\n# Stop web server\r\nsystemctl stop nginx 2>\/dev\/null || systemctl stop apache2 2>\/dev\/null || systemctl stop httpd 2>\/dev\/null\r\n\r\n# Renew certificates if they are due\r\ncertbot renew --quiet --non-interactive --post-hook \"systemctl start nginx 2>\/dev\/null || systemctl start apache2 2>\/dev\/null || systemctl start httpd 2>\/dev\/null\"\r\n\r\n# Start web server (post-hook handles this, but this is a safety net)\r\nsystemctl start nginx 2>\/dev\/null || systemctl start apache2 2>\/dev\/null || systemctl start httpd 2>\/dev\/null<\/code><\/pre>\nMake it executable and add a daily cron job:<\/p>\n
\r\n
sudo chmod +x \/usr\/local\/bin\/le-ip-renew.sh\r\nsudo crontab -e<\/code><\/pre>\nAdd this line to run the script daily at 3 AM (choose a low-traffic time):<\/p>\n
\r\n
0 3 * * * \/usr\/local\/bin\/le-ip-renew.sh > \/dev\/null 2>&1<\/code><\/pre>\n<\/i> When To Let UnderHost Handle It<\/h2>\n
This guide empowers you to manage SSL for IPs yourself. However, if your time is better spent on core development, or you need this scaled across multiple servers, our UnderManagement<\/a><\/strong> service is the answer.<\/p>\n
\n\nFor the Hands-On DevOps<\/h3>\n
- \n
- Follow the guide above.<\/li>\n
- Leverage our high-performance VPS<\/a> as your foundation.<\/li>\n
- Use @CustomerPanel<\/a> for any network or hardware queries.<\/li>\n<\/ul>\n<\/div>\n
\nFor Teams Focused on Scale<\/h3>\n
- \n
- Offload SSL management entirely to our experts.<\/li>\n
- Get 24\/7 monitoring, backup, and security hardening.<\/li>\n
- Ideal for dedicated server<\/a> deployments.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
<\/p>\n
<\/span>![\"\"](\"https:\/\/cdn.underhost.com\/android-chrome-192x192.webp\")
<\/span><\/div>\n\nBuild on a Secure, High-Performance Foundation<\/h2>\n
Whether you DIY or opt for full management, start with infrastructure you can trust.<\/p>\n
Deploy a Cloud VPS<\/a>Explore Managed Services<\/a><\/div>\n
<\/p>\n
\nFrequently Asked Questions: SSL for IP Addresses<\/h2>\n
\nQ: Can I get a wildcard certificate for an IP range?<\/h3>\n
No. Let’s Encrypt does not issue wildcard certificates for IP addresses. You must validate and obtain a certificate for each individual public IP address.<\/p>\n<\/div>\n
\nQ: Why does my browser show a certificate warning?<\/h3>\n
A valid Let’s Encrypt certificate for an IP address is trusted by current browsers when you open
https:\/\/<\/code> followed by that exact IP. If you see a warning, check that you opened the same IP address that is in the certificate, that the certificate has not expired (IP certificates last only about six days, so renewal must work), and that the server sends the full certificate chain.<\/p>\n<\/div>\n\nQ: What if a firewall blocks port 80?<\/h3>\n
IP certificates cannot use DNS validation, because an IP address has no DNS zone. Certbot validates them over port 80 (HTTP-01). The TLS-ALPN-01 challenge on port 443 is the other option, but Certbot does not support it, so you would need another ACME client. If neither port can be opened, use a domain name that points to the IP and a normal certificate, which can be validated through DNS.<\/p>\n<\/div>\n
\nQ: Does this work on UnderHost’s Offshore Servers?<\/h3>\n
Absolutely. The process is identical whether your offshore dedicated server<\/a> is in the Caribbean, Hong Kong or another of our locations, as long as port 80 is reachable from the internet for validation.<\/p>\n<\/div>\n
\nQ: I hit an error during validation. What should I check?<\/h3>\n
First, triple-check the prerequisites: public IP, open port 80, no CDN. Then, look at the specific Certbot error. Common issues include another process (like a forgotten
certbot<\/code> instance) already using port 80, or a firewall rule on your server or at the datacenter level. Our support team via @CustomerPanel<\/a> can assist with network-level diagnostics.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
- Use @CustomerPanel<\/a> for any network or hardware queries.<\/li>\n<\/ul>\n<\/div>\n
- ✅ Open Ports 80 & 443:<\/strong> Let’s Encrypt must validate your control over the IP via HTTP on port 80. Ensure your firewall (e.g.,
- Staging & Testing Environments:<\/strong> Configuring HTTPS for pre-production servers before DNS records are pointed to them.<\/li>\n