Let’s Encrypt on Linux server refers to installing and managing free SSL/TLS certificates from the Let’s Encrypt Certificate Authority using the ACME protocol (commonly via Certbot).
It enables HTTPS, automatic renewals, and secure configurations for Apache, Nginx, and reverse proxies across distributions like Ubuntu, Debian, AlmaLinux, Rocky Linux, and CentOS.
If you’re new to HTTPS, learning how to use Let’s Encrypt on a Linux server is the fastest, most cost-effective way to secure your site.
You’ll understand how Let’s Encrypt works, how to install it with Certbot on popular distros, automate renewals, fix common errors, and apply best-practice hardening.
What Is Let’s Encrypt and How Does It Work?
Let’s Encrypt is a free, automated, open certificate authority that issues Domain Validation (DV) certificates.
Using the ACME protocol, a client like Certbot proves domain control (via HTTP-01 or DNS-01 challenges) and retrieves a signed TLS certificate for your domain. Certificates are valid for 90 days and are designed to be renewed automatically.
Key components you’ll use:-
- ACME Client (Certbot): Handles challenges, issuance, and renewal.
- Challenges: HTTP-01 (file served over port 80) or DNS-01 (TXT record; required for wildcard certificates).
- Web Server Integrations: Apache and Nginx plugins can configure virtual hosts automatically.
Benefits and Limitations
Why most websites choose Let’s Encrypt:-
- Free SSL/TLS certificates with broad browser trust.
- Automation-first: seamless issuance and auto-renewal.
- Fast setup with Certbot plugins for Apache and Nginx.
- Supports ECDSA and RSA keys, SAN and wildcard certificates (via DNS-01).
Consider these limitations:-
- DV only: no Organization Validation (OV) or Extended Validation (EV).
- 90-day validity: automation is essential; manual management is risky.
- Rate limits: avoid excessive requests during testing; use the staging environment.
Prerequisites for Installing Let’s Encrypt on a Linux Server
- A registered domain with correct DNS A/AAAA records pointing to your server.
- Open ports: 80 (HTTP) and 443 (HTTPS) reachable from the internet.
- Sudo/root access to your Linux server (Ubuntu/Debian/AlmaLinux/Rocky Linux/CentOS).
- Apache or Nginx installed (or a reverse proxy arrangement).
- For wildcard certificates: API credentials for your DNS provider or ability to add TXT records.
Install Certbot on Popular Linux Distributions
Ubuntu and Debian (Snap Recommended)
Using Snap ensures you get the latest Certbot and plugins:
sudo apt update
sudo apt install snapd -y
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbotAlmaLinux, Rocky Linux, RHEL, CentOS
Use the distribution packages or EPEL where needed:
# AlmaLinux/Rocky/RHEL 8/9
sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-nginx python3-certbot-apacheIssue and Install Certificates (Apache, Nginx, Standalone)
Apache: Automatic Configuration
Certbot’s Apache plugin can fetch and configure HTTPS with redirects automatically:
sudo certbot --apache -d example.com -d www.example.comDuring prompts, choose the option to redirect HTTP to HTTPS.
Nginx: Automatic Configuration
Ensure your server block has the correct server_name values before running:
sudo certbot --nginx -d example.com -d www.example.comStandalone or Webroot (For Reverse Proxies or Custom Setups)
If no web server is running, use standalone (it binds to port 80). Stop any service using port 80 first:
sudo systemctl stop nginx apache2 httpd
sudo certbot certonly --standalone -d example.com -d www.example.com
sudo systemctl start nginx apache2 httpdAlternatively, use webroot if your files are served from a known path:
sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.comWildcard Certificates with DNS-01
Wildcard certificates (e.g., *.example.com) require DNS-01. Use a DNS plugin (Cloudflare shown as example):
# Ubuntu/Debian (if using APT packages instead of Snap)
sudo apt install -y python3-certbot-dns-cloudflare
# Create credentials file
sudo mkdir -p /root/.secrets
sudo nano /root/.secrets/cloudflare.ini
# Add:
# dns_cloudflare_api_token = <YOUR_TOKEN>
sudo chmod 600 /root/.secrets/cloudflare.ini
# Request wildcard + apex
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
-d example.com -d *.example.comPoint your web server to the certificate paths printed by Certbot (usually under /etc/letsencrypt/live/example.com/).
Enable HTTPS and Best-Practice TLS Settings
Nginx example
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
root /var/www/html;
index index.html index.php;
}Apache example
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com/
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
DocumentRoot /var/www/html
</VirtualHost>
</IfModule>Enable required modules for Apache: ssl, headers, rewrite (on Debian/Ubuntu: a2enmod ssl headers rewrite).
Automate Renewals and Monitoring
Certbot installs a systemd timer or cron job to renew certificates automatically around day 60–70. Always test renewals after setup:
sudo certbot renew --dry-runCheck systemd timers (if using Snap on Ubuntu/Debian):
systemctl list-timers | grep certbotIf your web server needs a reload on renewal, add a deploy hook:
sudo certbot renew --deploy-hook "systemctl reload nginx"Troubleshooting Common Let’s Encrypt Errors
- Challenge failed (HTTP-01 404/403): Ensure DNS points to the correct server, port 80 is open, and the server_name/webroot matches your domain.
- Port 80 blocked: Let’s Encrypt requires HTTP for HTTP-01. Temporarily allow it in firewalls or use DNS-01.
- Wrong vhost: The ACME challenge file may be served from another vhost. Make sure the requested domain’s vhost is active and enabled.
- Behind a reverse proxy/CDN: Use DNS-01 or ensure the proxy passes /.well-known/acme-challenge to the origin unchanged.
- SELinux denials (RHEL family): Review audit logs and adjust contexts with semanage/restorecon if needed.
- Rate limits: Use the staging server during testing: –staging, then switch to production.
Advanced Usage: Wildcards, Multi-Domain, ECDSA Keys
Subject Alternative Names (SAN)
Request multiple domains in one certificate to simplify management:
sudo certbot --nginx -d example.com -d www.example.com -d blog.example.comECDSA vs RSA
ECDSA keys are smaller and faster. To prefer ECDSA (supported by most clients):
sudo certbot certonly --key-type ecdsa --elliptic-curve secp384r1 --nginx -d example.comStaging and Zero-Downtime Testing
Use the staging environment to test automations without hitting rate limits:
sudo certbot --nginx --staging -d example.comSecurity and Hardening Best Practices
- Redirect HTTP to HTTPS and enable HSTS for strict transport.
- Limit TLS versions to TLSv1.2+; prefer TLSv1.3 where possible.
- Use ECDSA keys when feasible; keep private keys readable by root only.
- Enable OCSP stapling for faster, private revocation checks.
- Automate renewals with alerts (email logs, monitoring hooks).
- Back up /etc/letsencrypt (certificates, keys, renewal configs) securely.
Real-World Scenarios and Tips
- Single site on VPS: Use –nginx or –apache for fastest setup; verify auto-renewal.
- Multiple apps/domains: Consider SAN certs or one cert per site. Document certificate paths per vhost.
- Reverse proxy (e.g., Nginx front, apps behind): Terminate TLS at the proxy; use webroot or DNS-01 for issuance.
- Behind Cloudflare: Either use Cloudflare‘s “Full (strict)” with an origin certificate or obtain Let’s Encrypt via DNS-01 to avoid challenge issues.
- CI/CD pipelines: Use staging for test deploys; promote to production with the same flow to avoid surprises.
FAQ’s: Let’s Encrypt on Linux Server
Is Let’s Encrypt really free and trusted by browsers?
Yes. Let’s Encrypt is a widely trusted CA included in all major browsers and operating systems. It issues Domain Validation certificates at no cost, suitable for encrypting traffic and proving domain control.
How do I set up automatic renewal, and what if it fails?
Certbot installs a systemd timer or cron job to renew around day 60. Test with certbot renew –dry-run. If renewal fails, check logs in /var/log/letsencrypt/ and ensure ports and DNS are correct. Add deploy hooks to reload your web server after renewal.
Can I get a wildcard certificate with Let’s Encrypt?
Yes, via DNS-01 challenge only. Use a DNS plugin (e.g., Cloudflare, Route 53) or add TXT records manually. Request both the apex (example.com) and wildcard (*.example.com) to cover all hosts.
Does Let’s Encrypt work behind a CDN or reverse proxy?
It does, but HTTP-01 can break if the CDN intercepts the challenge. Either allow the ACME path through to origin, temporarily bypass the CDN during issuance, or use DNS-01 for a reliable setup without exposing port 80 publicly.
Should I use RSA or ECDSA certificates?
ECDSA offers better performance and smaller keys, widely supported by modern clients. For maximum compatibility with legacy devices, you can provision dual certs on some stacks, but for most sites ECDSA (P-256 or P-384) is an excellent default.
By following this guide, you can deploy Let’s Encrypt on your Linux server confidently, automate renewals, and enforce strong TLS. If you need a done-for-you solution with 24/7 support, YouStable’s managed hosting ensures your certificates and security never become a bottleneck.
