If you’re running a website on Linux and it’s still serving pages over plain HTTP, you’re leaving your visitors exposed. Learning how to install Let’s Encrypt on Linux with Certbot is one of the single most impactful things you can do for your server’s security. The best part? It’s completely free, takes about ten minutes, and you’ll have a trusted SSL certificate protecting every connection to your site.
Let’s Encrypt now powers 63.9% of all SSL certificates on the web. Certbot, the tool we’ll use today, runs on over 4 million servers and protects more than 31 million websites. I’ve been setting up Certbot on everything from tiny VPS instances to production clusters for years, and the process keeps getting smoother. If you have a reliable Linux VPS and a domain name, you’re ready to go.
Why Let’s Encrypt Is the Standard (Not Just the Free Option)
When I first started managing servers professionally, SSL certificates cost $100 to $200 per year. I remember watching a small business client hesitate over renewing a basic DV cert because of the price tag. That moment stuck with me. When Let’s Encrypt launched, it didn’t just make HTTPS free. It made HTTPS expected.
“HTTPS is no longer a feature, it’s the foundation of trust on the web.” — Troy Hunt, Security Researcher
Get a VPS from as low as $11/year! WOW!
Today, Let’s Encrypt issues millions of certificates daily. In September 2025, they hit a milestone: 10 million certificates issued in a single day. The 90-day certificate lifecycle might seem like a hassle, but it’s actually a security feature. Short-lived certs reduce the damage window if a private key gets compromised. And with Certbot handling auto-renewal, you’ll never have to think about it.
As of March 2026, Let’s Encrypt certificate statistics confirm their dominance. They’ve even started supporting IP address certificates, meaning you no longer need a domain to get SSL. That’s a game changer for development environments and internal tools.
Prerequisites Before You Start
Before we touch Certbot, let’s make sure your server is ready. Skipping these steps is the number one reason I see beginners fail on their first attempt.
A Domain Name Pointing to Your Server (DNS A Record)
Your domain’s DNS A record must point to your server’s public IP address, and that record needs to be fully propagated. This trips up more people than any other step. If you just updated your DNS, give it 15 to 30 minutes before running Certbot. You can verify propagation with:
dig yourdomain.com A +shortIf the output shows your server’s IP, you’re good.
Nginx Already Installed and Running
Certbot’s Nginx plugin reads your server_name directive to know which domains to issue certificates for. If Nginx isn’t running or configured, Certbot will fail. Follow our Nginx setup guide if you haven’t done this yet.
Ports 80 and 443 Open in Your Firewall
Let’s Encrypt validates domain ownership through an HTTP-01 challenge on port 80. Port 443 is where your HTTPS traffic will flow. Both must be open.
Quick Firewall Commands
- UFW (Ubuntu/Debian):
sudo ufw allow 'Nginx Full'— then configure UFW to open ports 80 and 443 - firewalld (RHEL/Fedora/Rocky):
sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --permanent --add-service=https && sudo firewall-cmd --reload— see our firewalld for RHEL-based systems guide
One critical detail: port 80 must stay open even after you configure HTTPS. Certbot needs it every time it renews your certificate. I’ve seen people close port 80 thinking they don’t need it anymore, then wonder why their cert expired 90 days later.
Step 1: Install Certbot on Linux
The Electronic Frontier Foundation maintains Certbot and recommends the snap package for most Linux distributions. Snap ensures you always get the latest version with automatic updates. Head to Certbot by EFF for the official instructions, or follow along below.
Ubuntu and Debian (Snap Method — Recommended)
# Remove any old certbot packages first
sudo apt remove certbot -y 2>/dev/null
# Install via snap
sudo snap install --classic certbot
# Create a symlink so you can run certbot from anywhere
sudo ln -s /snap/bin/certbot /usr/bin/certbot
# Verify
certbot --versionSnap handles updates automatically. You won’t need to manually upgrade Certbot again.
RHEL, Fedora, and Rocky Linux (dnf Method)
# Install certbot and the Nginx plugin
sudo dnf install certbot python3-certbot-nginx -y
# Verify
certbot --versionThe python3-certbot-nginx plugin is what lets Certbot automatically edit your Nginx configuration. Don’t skip it.
Step 2: Obtain Your SSL Certificate
This is where the magic happens. Certbot will talk to Let’s Encrypt’s servers, prove you own the domain, and install a trusted certificate on your server.
Using the Nginx Plugin (Recommended — Edits Config Automatically)
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.comOn first run, Certbot will ask you to:
- Enter an email address for renewal notices
- Agree to the Let’s Encrypt Terms of Service
- Optionally share your email with the EFF
Behind the scenes, Certbot uses the HTTP-01 and DNS-01 challenge types to validate that you control the domain. The HTTP-01 challenge places a temporary file at /.well-known/acme-challenge/ on your server, then Let’s Encrypt fetches it over port 80.
The Nginx plugin automatically edits your config in /etc/nginx/sites-available/, adding the SSL directives and certificate paths. Your certificate files end up in:
/etc/letsencrypt/live/yourdomain.com/fullchain.pem— your certificate plus intermediates/etc/letsencrypt/live/yourdomain.com/privkey.pem— your private key
Using Standalone Mode (No Web Server Running Yet)
If Nginx isn’t running yet, standalone mode spins up a temporary web server for the challenge:
sudo certbot certonly --standalone -d yourdomain.comYou’ll need to manually configure Nginx with the certificate paths afterward. I generally recommend the Nginx plugin method. It saves time and reduces the chance of a typo in your config.
Step 3: Verify HTTPS Is Working
Don’t just check the padlock icon and call it a day. Verify your SSL setup properly with these commands:
Verification Checklist
- Visit
https://yourdomain.comin your browser — confirm the padlock appears - Run
curl -I https://yourdomain.com— look forHTTP/2 200 - Check your cert details:
sudo certbot certificates - Use openssl to inspect your TLS certificate:
openssl s_client -connect yourdomain.com:443 - Run the SSL Labs test at ssllabs.com/ssltest — aim for an A rating
The certbot certificates command is especially useful. It shows every certificate on your server, their expiry dates, and file paths. I run it after every new cert install just to double-check.
Step 4: Set Up HTTP to HTTPS Redirect
When Certbot runs with the --nginx flag, it typically asks if you want to redirect all HTTP traffic to HTTPS. Say yes. If you missed that prompt or need to set it up manually, add this to your Nginx config’s port 80 server block:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}Keep the port 80 server block alive. The ACME challenge location at /.well-known/acme-challenge/ runs over HTTP, so deleting the entire port 80 block will break auto-renewal.
After any Nginx config change, always test before reloading:
sudo nginx -t && sudo systemctl reload nginxIf you’re not comfortable with systemctl to check and reload Nginx, check out our guide. It covers start, stop, reload, and status checks for any service.
Step 5: Test and Confirm Auto-Renewal
Let’s Encrypt certificates expire in 90 days. Auto-renewal isn’t optional. It’s the whole reason this system works.
Certbot installs a systemd timer that runs twice daily. It checks whether any certificates will expire within 30 days and renews them if needed. Verify the timer is active:
systemctl status snap.certbot.renew.timerRun a dry test to confirm everything works without actually renewing:
sudo certbot renew --dry-runIf the dry run succeeds, your server will handle renewals silently in the background. If you want extra peace of mind, set up a cron job for manual renewal monitoring that emails you if a cert is close to expiry.
I learned the hard way why this matters. A few years back, I added a restrictive firewall rule on a production server and didn’t think twice about it. Three months later, the SSL renewal failed silently because port 80 was blocked. The site went down with an expired cert on a Friday evening. Since then, I run --dry-run after every firewall change. No exceptions.
Common Certbot Errors and How to Fix Them
Even when you follow every step, things can go wrong. Here are the errors I see most often and how to fix them.
Error: Port 80 Is Blocked or In Use
Certbot can’t complete the HTTP-01 challenge if port 80 is blocked by a firewall or occupied by another process. Check your firewall with UFW, firewalld, or iptables rules, and make sure Nginx is actually listening on port 80:
sudo ss -tlnp | grep :80Error: Too Many Certificates Already Issued (Rate Limit Hit)
Let’s Encrypt limits you to 50 duplicate certificates per registered domain per week. If you’re testing, always use the staging flag:
sudo certbot --nginx --staging -d yourdomain.comStaging certificates aren’t trusted by browsers, but they let you test the entire flow without burning through rate limits.
Error: DNS Domain Does Not Resolve to This Server
Before running Certbot, verify your DNS is pointing correctly:
dig yourdomain.com A +short
nslookup yourdomain.comIf the IP doesn’t match your server, wait for DNS propagation or fix your DNS records.
What’s New in Let’s Encrypt for 2026
Let’s Encrypt keeps evolving. Here’s what changed recently:
- IP address certificates: As of March 2026, Certbot and Let’s Encrypt now support IP address certificates. You can get a free SSL cert for a raw IP address without needing a domain. Huge for homelab setups and internal tools.
- Short-lived 6-day certificates: A new option that reduces the compromise window if your private key leaks. Think of it as the difference between GPG for key management and encryption at a personal level and automated key rotation at scale.
- New root certificates: Rolling out for broader device compatibility, especially older Android devices.
The IP address certificate feature alone is worth paying attention to. I’ve already started using it on a few homelab machines that don’t have public domains, and the setup is almost identical to the standard flow.
Essential Certbot Commands Quick Reference
| Command | What It Does |
|---|---|
certbot --nginx -d domain.com |
Obtain and configure a cert for Nginx |
certbot renew --dry-run |
Test renewal without making changes |
certbot renew |
Manually trigger renewal for all certs |
certbot certificates |
List all certs with expiry dates |
certbot delete --cert-name domain.com |
Remove a certificate |
certbot --nginx --staging -d domain.com |
Test without hitting rate limits |
systemctl status snap.certbot.renew.timer |
Check auto-renewal timer |
Bookmark this table. You’ll come back to it more often than you’d expect.
Secure Your Server Beyond SSL
Getting Let’s Encrypt running with Certbot is a huge step, but it’s just the beginning of properly hardening a Linux server. Now that your traffic is encrypted, consider these next moves:
- Set up fail2ban to block brute force attacks against SSH and your web server
- Switch to SSH key setup and disable password authentication
- Deploy a WireGuard VPN server on Linux for secure remote access to internal services
Each of those guides walks you through the full process the same way we did here: step by step, with real commands you can copy and run. If you’ve just set up Certbot for the first time and everything is working, take a minute to enjoy that green padlock. Then keep going. A secure server isn’t built in one sitting, but you just took the most important step.
