<\/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
\n
The 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<\/blockquote>\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
\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>
\nExplore Managed Services<\/a>\n<\/div>\n<\/p>\n
\nSSL for IPs: Frequently Asked Questions<\/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 still show a “Not Secure” warning?<\/h3>\n
This is normal for IP-based certificates. The warning is related to domain name validation<\/strong>, not the encryption itself. The padlock in the URL bar and the SSL\/TLS connection are fully encrypted. Browsers expect a domain name, not an IP, in the certificate’s Subject Alternative Name (SAN) field. Advanced users and API clients will trust the connection.<\/p>\n<\/div>\n
\nQ: What if I’m behind a restrictive firewall that blocks port 80?<\/h3>\n
You cannot use the HTTP-01 challenge method required for IP certificates. Your only alternative is to use a traditional domain-based certificate (even if it points to an IP) and validate it via the DNS-01 challenge, which doesn’t require an open port 80.<\/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 our Bulletproof Datacenter. Our network is configured to allow the necessary validation traffic.<\/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","protected":false},"excerpt":{"rendered":"For DevOps engineers and system administrators, the ability to secure a service at the IP level is a game-changer. Forget DNS complexities for internal projects. This definitive guide walks you through installing, configuring, and automating Let’s Encrypt IP-based SSL certificates on any Linux server with a public IP.<\/p>\n","protected":false},"author":1,"featured_media":5436,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16,1,11,24,29,20,80],"tags":[],"class_list":["post-5543","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","category-news","category-how-to","category-install","category-ip","category-ssh","category-ssl"],"_links":{"self":[{"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/posts\/5543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/comments?post=5543"}],"version-history":[{"count":2,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/posts\/5543\/revisions"}],"predecessor-version":[{"id":5546,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/posts\/5543\/revisions\/5546"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/media\/5436"}],"wp:attachment":[{"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/media?parent=5543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/categories?post=5543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/underhost.com\/blog\/wp-json\/wp\/v2\/tags?post=5543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- 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