🔒 security

Securing Websites with Let's Encrypt SSL Certificates

Learn how to obtain and renew free SSL/TLS certificates using Certbot. This comprehensive guide covers automatic renewal, multiple domains, and production-ready configurations.

Published:
Author: ServerHi Editorial Team
Let's Encrypt SSL certificates securing website connections with lock icons

Introduction

Transport Layer Security, commonly known as SSL/TLS, forms the foundation of secure internet communication. When visitors access your website, SSL certificates encrypt the data transmitted between their browsers and your server, protecting sensitive information from interception and tampering. Beyond security benefits, search engines like Google prioritize websites with valid SSL certificates, making encryption essential for both protection and visibility.

Let’s Encrypt, a free, automated, and open certificate authority launched in 2015, revolutionized how website operators implement SSL. Previously, SSL certificates cost money and required manual verification processes. Let’s Encrypt eliminated these barriers by providing free certificates through an automated process that anyone can set up in minutes. Millions of websites now use Let’s Encrypt certificates, contributing to a more secure and privacy-respecting web.

This guide walks you through obtaining SSL certificates using Certbot, the most widely deployed Let’s Encrypt client. You will learn how to secure Nginx and Apache web servers, configure automatic renewal, handle multiple domains, and implement production-ready configurations. By the end of this tutorial, your website will serve all traffic over HTTPS with valid, auto-renewing certificates.

Why SSL Certificates Matter

Learn the importance of SSL certificates to appreciate why implementation matters for every website, regardless of content or audience size.

Data Encryption and Privacy

Every piece of data transmitted between a user’s browser and your server travels through numerous network points, including routers, switches, and potentially malicious actors. Without encryption, anyone with network access can intercept passwords, session cookies, personal information, and any other data exchanged during the visit. SSL encryption creates a secure tunnel through which all data travels encoded, making interception useless without the decryption key.

This protection matters especially for websites handling sensitive information: login forms, payment pages, admin dashboards, and any page where users enter personal data. Even informational websites benefit from encryption because browsers increasingly warn visitors when connections lack SSL, creating poor first impressions and potentially driving traffic away.

Search Engine Optimization Benefits

Google announced HTTPS as a ranking signal in 2014, meaning websites with valid SSL certificates receive slight preference in search results. While the boost remains relatively small compared to content quality factors, every advantage matters in competitive search landscapes. More importantly, browsers display security warnings for non-HTTPS sites, which significantly impact user behavior and bounce rates.

Trust and Professionalism

The padlock icon in browser address bars has become a universal symbol of trustworthiness. Visitors increasingly recognize this visual cue and associate it with legitimate, professionally managed websites. Without SSL, browsers display warnings that make your site appear dangerous or untrustworthy, regardless of actual content quality.

Prerequisites

Before proceeding with certificate installation, ensure your environment meets these requirements and you have necessary access.

You need a registered domain name pointing to your server’s IP address. Let’s Encrypt validates domain ownership by checking that your server responds to requests for the domain you are requesting a certificate for. Ensure DNS records propagate before attempting certificate issuance, as validation failures will prevent certificate generation.

Your server must run a supported web server (Nginx or Apache) on ports 80 and 443. The web server must be accessible from the internet on port 80 for the initial validation process. Firewalls must allow incoming connections on these ports.

You require sudo access or root privileges on your server to install packages and modify web server configurations. The Certbot package manager installation process varies by operating system, so ensure you know your server’s distribution and version.

Finally, backup your current web server configuration before making changes. While the installation process is generally safe, having a restore point prevents potential downtime if unexpected issues arise.

Installing Certbot

Certbot installation differs across operating systems. This section covers installation for the most common server environments, ensuring you have a working client for certificate management.

Ubuntu and Debian

On Ubuntu and Debian systems, Certbot is available through the official package repositories. However, the versions provided may lag behind the latest releases. For the most current features and security updates, use the Certbot PPA (Personal Package Archive) maintained by the Electronic Frontier Foundation.

# Update package lists
sudo apt update

# Install Certbot and Nginx plugin
sudo apt install certbot python3-certbot-nginx

# Verify installation
certbot --version

The output should display a version number, confirming successful installation. The Nginx plugin simplifies certificate installation by automatically configuring your server based on the certificate details.

CentOS and RHEL

CentOS and RHEL systems require enabling the EPEL (Extra Packages for Enterprise Linux) repository before installing Certbot. The process differs slightly between CentOS 7 and newer versions.

# Enable EPEL repository
sudo dnf install epel-release

# Install Certbot and Apache plugin
sudo dnf install certbot python3-certbot-apache

# Verify installation
sudo certbot --version

Standalone Installation

For servers where package manager installation fails or is unavailable, you can install Certbot using snap packages or by downloading the software directly. Snap installations work across most modern Linux distributions.

# Install via snap (requires snapd)
sudo snap install --classic certbot

# Create symlink for system access
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Verify installation
certbot --version

Obtaining Your First Certificate

With Certbot installed, you can now request your first SSL certificate. The process involves domain validation, certificate generation, and optional automatic web server configuration.

Interactive Installation

The simplest method uses Certbot’s interactive mode, which prompts you for necessary information and handles configuration automatically. Run the command for your web server, replacing example.com with your actual domain name.

# For Nginx
sudo certbot --nginx -d example.com -d www.example.com

# For Apache
sudo certbot --apache -d example.com -d www.example.com

The -d flags specify the domains for which you are requesting certificates. The first domain listed becomes the primary certificate name. Multiple domains on a single certificate work well for websites serving the same content across different domain names.

During the process, Certbot prompts you for an email address for renewal notifications and asks whether to redirect HTTP traffic to HTTPS. Choosing the redirect option ensures all visitors use encrypted connections, maximizing security benefits.

Non-Interactive Installation

For automation scripts or environments without interactive prompts, provide all necessary information through command-line arguments.

# Nginx with automatic redirect
sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --redirect

# Standalone validation (no web server configuration)
sudo certbot certonly \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --standalone

The certonly mode generates certificates without modifying your web server configuration. This approach suits advanced users who prefer manual control over their server settings.

Understanding Certificate Files

After successful certificate issuance, Certbot stores your certificates in a specific directory structure. Understanding these files and their purposes helps with manual configuration and troubleshooting.

# Certificate location
/etc/letsencrypt/live/example.com/

# Files in this directory
# cert.pem - The server certificate
# chain.pem - The intermediate certificate
# fullchain.pem - Server certificate + intermediate(s)
# privkey.pem - Private key (keep secret!)

The fullchain.pem file contains everything needed for most server configurations, combining your certificate with the intermediate certificate that browsers use to validate your certificate’s chain of trust. The privkey.pem file contains your private key, which must remain secret and accessible only to the web server process.

Verify your certificate details using the OpenSSL command line tool:

# View certificate details
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -text -noout

# Check certificate expiration
openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/cert.pem

# Verify certificate chain
openssl verify -CAfile /etc/letsencrypt/live/example.com/chain.pem \
  /etc/letsencrypt/live/example.com/cert.pem

Configuring Nginx for SSL

If you chose automatic configuration during certificate issuance, Certbot already modified your Nginx configuration. Understanding the configuration helps you customize settings and troubleshoot issues.

A typical SSL-enabled Nginx server block includes several important directives:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;

    # SSL certificate paths
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # SSL configuration - modern security settings
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Security headers
    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    # Document root and site files
    root /var/www/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

The Strict-Transport-Security header, known as HSTS, instructs browsers to only connect via HTTPS for the specified duration. Setting this header prevents downgrade attacks and ensures encrypted connections even when users visit through HTTP links.

Redirect HTTP to HTTPS

For servers where Certbot did not handle redirection automatically, add a dedicated redirect server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

This configuration catches all HTTP requests and redirects them to HTTPS with a 301 (permanent) status code. Browsers remember this redirect, so subsequent visits from the same user automatically use HTTPS.

Configuring Apache for SSL

Apache installations receive similar automatic configuration from Certbot. Manual configuration or understanding generated settings follows this pattern.

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    # Modern SSL settings
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder off
    SSLSessionTickets off

    # Security headers
    Header always set Strict-Transport-Security "max-age=63072000"

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Redirect HTTP to HTTPS in Apache by modifying the port 80 VirtualHost:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Automatic Certificate Renewal

Let’s Encrypt certificates expire after 90 days, requiring renewal before expiration. Certbot includes automatic renewal functionality that handles this process without manual intervention.

Testing Automatic Renewal

Before relying on automated renewal, test the configuration to ensure it works correctly:

# Test renewal (dry run)
sudo certbot renew --dry-run

# Check renewal timer status (systemd systems)
sudo systemctl status certbot.timer

# View renewal logs
sudo journalctl -u certbot-renewal.service

The dry-run mode simulates the renewal process without actually generating new certificates. Watch the output for any errors, as configuration issues often surface during these tests.

Configuring Systemd Timers

On systems using systemd (most modern Linux distributions), Certbot installation includes a timer that checks for renewal twice daily. This frequent checking ensures certificates renew even if the initial attempt fails.

# Enable and start the timer
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

# View timer schedule
sudo systemctl list-timers certbot.timer

# Manually trigger renewal
sudo certbot renew

The timer runs certbot renew twice daily at randomized minutes, preventing thousands of servers from requesting renewal simultaneously, which would overload Let’s Encrypt servers.

Configuring Cron Jobs

Older systems or those without systemd use cron for scheduled tasks:

# Edit crontab
sudo crontab -e

# Add this line to run renewal twice daily
0 0,12 * * * /usr/bin/certbot renew --quiet

The --quiet flag suppresses output unless errors occur, keeping your system logs clean while ensuring certificates renew silently in the background.

Managing Multiple Domains and Subdomains

Production websites often serve multiple domains or subdomains. Let’s Encrypt certificates can cover multiple names on a single certificate, simplifying management.

Multiple Domains on One Certificate

Request certificates covering multiple domains in a single command:

# Certificate covering main domain and www subdomain
sudo certbot --nginx -d example.com -d www.example.com

# Certificate covering multiple unrelated domains
sudo certbot --nginx \
  -d example.com -d www.example.com \
  -d anotherdomain.com -d www.anotherdomain.com

Let’s Encrypt limits certificates to 100 domain names per certificate. This limit accommodates most multi-domain scenarios while preventing abuse.

Wildcard Certificates

Wildcard certificates cover all subdomains of a domain using a single certificate. This approach simplifies certificate management for websites with many subdomains.

# Request wildcard certificate
sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d example.com \
  -d *.example.com

Wildcard certificates require DNS-based validation, where you prove domain ownership by adding a specific TXT record to your DNS configuration. Certbot prompts you with the exact record to create.

Separate Certificates Per Domain

For larger deployments, managing separate certificates per domain provides better isolation and simplifies revocation if needed:

# Certificate for example.com
sudo certbot --nginx -d example.com

# Certificate for subdomain.example.com
sudo certbot --nginx -d subdomain.example.com

This approach increases the number of certificates to manage but allows independent renewal schedules and reduces the blast radius if any single certificate is compromised.

Troubleshooting Common Issues

Certificate installation and renewal can encounter various issues. Understanding common problems and their solutions helps maintain continuous SSL coverage.

Validation Failures

Domain validation failures occur when Let’s Encrypt cannot connect to your server on port 80. Common causes include firewalls blocking port 80, DNS records not yet propagated, and web servers not running.

# Verify port 80 is accessible from the internet
curl -I http://example.com/.well-known/acme-challenge/test

# Check DNS resolution
dig example.com

# Verify web server is running
sudo systemctl status nginx

Ensure your firewall allows both incoming and outgoing connections on port 80. Some hosting providers block this port by default, requiring configuration changes in their control panels.

Certificate Renewal Failures

Renewal failures often stem from web server configuration changes that prevent Certbot from accessing the validation path. This commonly happens after server migrations or configuration updates.

# Check detailed renewal error
sudo certbot renew --verbose

# Manual certificate issuance to see specific errors
sudo certbot certonly --debug-challenges

When renewal fails, examine the full error output. Common solutions include temporarily disabling security modules that block access to the .well-known directory and ensuring the web server configuration has not been modified to block ACME validation paths.

Mixed Content Warnings

After enabling HTTPS, browsers may display mixed content warnings if your pages reference resources over HTTP. This happens when HTML contains links to images, scripts, or stylesheets using HTTP URLs.

# Find mixed content references
grep -r "http://" /var/www/html/

# Use relative URLs or HTTPS in content
sed -i 's|http://|https://|g' /var/www/html/*.html

Update all internal links to use HTTPS or protocol-relative URLs (//example.com/script.js) that automatically use the current page’s protocol.

Expired Certificates

If certificates expire before renewal, websites become inaccessible. Emergency recovery requires immediate certificate reissuance:

# Force immediate renewal
sudo certbot renew --force-renewal

# If renewal fails completely, obtain new certificate
sudo certbot certonly --force-renewal -d example.com

# Restart web server after certificate update
sudo systemctl restart nginx

Monitor certificate expiration proactively using monitoring tools that alert you before certificates expire. Services like SSL Labs (ssllabs.com/ssltest) provide detailed certificate analysis and expiration warnings.

Production Best Practices

Implementing SSL in production environments requires attention to security, performance, and reliability considerations beyond basic installation.

Certificate Backup and Recovery

Maintain backups of certificates and private keys in secure storage. While Let’s Encrypt makes obtaining new certificates easy, having backups prevents downtime during unexpected situations.

# Backup certificates (store securely!)
sudo tar -czf /backup/ssl-certs-$(date +%Y%m%d).tar.gz \
  /etc/letsencrypt/

# Encrypt backups with GPG for additional security
gpg --symmetric --cipher-algo AES256 \
  /backup/ssl-certs-$(date +%Y%m%d).tar.gz

Store backup encryption keys separately from the backups themselves, perhaps in a password manager or secure physical storage.

Monitoring and Alerting

Implement monitoring that alerts you before certificates expire. Many monitoring services check SSL certificate validity and send notifications:

# Check days until expiration in scripts
DAYS=$(openssl x509 -enddate -noout \
  -in /etc/letsencrypt/live/example.com/cert.pem \
  | cut -d= -f2)
echo "Certificate expires in $DAYS days"

Integrate this check into your existing monitoring system or set up a simple cron job that sends email alerts when certificates approach their 30-day renewal window.

Performance Optimization

SSL encryption adds computational overhead, but modern hardware and optimized configurations minimize performance impact.

Enable HTTP/2 to improve connection efficiency. HTTP/2 multiplexes multiple requests over a single connection, reducing latency for pages loading many resources:

server {
    listen 443 ssl http2;
    # ... rest of configuration
}

Connection keep-alives reduce the overhead of establishing new TLS connections for subsequent requests. Ensure your keep-alive timeout settings accommodate typical user behavior patterns.

Conclusion

Securing your website with Let’s Encrypt SSL certificates protects visitor data, improves search engine rankings, and demonstrates professionalism. The automated nature of Certbot makes implementation accessible to administrators of all experience levels, while the 90-day renewal cycle ensures continuous security through regular certificate management.

Regularly verify your SSL configuration using tools like SSL Labs’ SSL Test to ensure you are using modern, secure settings. As SSL standards evolve, staying current with best practices keeps your website secure against emerging threats.

Consider extending your security implementation with additional measures like Content Security Policy headers, certificate transparency monitoring, and automated security scanning. These complementary practices build defense-in-depth that protects your infrastructure and users.

Related Guides:

Tags

#SSL #TLS #Certbot #HTTPS #Let's Encrypt #Nginx #security

Related Tutorials