L18. TLS Certificates: Let's Encrypt and Certificate Management

What TLS Is and Why It Matters

TLS (Transport Layer Security) is the protocol that encrypts communication between a client and a server. When you see the padlock icon in a browser, TLS is what makes that connection private. Without TLS, data travels across the network in plaintext, meaning anyone who can intercept the traffic (on the same Wi-Fi network, at an ISP, or through a compromised router) can read it.

For security professionals, TLS is non-negotiable. It protects:

• Login credentials from being captured in transit
• API tokens and session cookies from interception
• Sensitive data like payment information and personal records
• Internal service-to-service communication from eavesdropping

The older term "SSL" (Secure Sockets Layer) still appears in many tools and documentation, but SSL is deprecated. Modern systems use TLS 1.2 or TLS 1.3. When someone says "SSL certificate," they almost always mean a TLS certificate.

How Certificates Work: The Chain of Trust

A TLS certificate is a digitally signed document that binds a public key to a domain name. When your browser connects to https://example.com, the server presents its certificate, and the browser verifies it by checking a chain of trust:

1. Server certificate: Issued for the specific domain (e.g., example.com)
2. Intermediate certificate: Issued by the Certificate Authority (CA) and used to sign the server certificate
3. Root certificate: Pre-installed in your browser or operating system's trust store

If every link in this chain is valid and none of the certificates are expired or revoked, the browser trusts the connection.

What Goes Wrong Without Valid Certificates

Let's Encrypt and Certbot

Let's Encrypt is a free, automated Certificate Authority that issues domain-validated TLS certificates. Certbot is the official command-line tool for requesting and managing Let's Encrypt certificates.

Installing Certbot

# Ubuntu/Debian
sudo apt update && sudo apt install -y certbot
# If using Nginx
sudo apt install -y python3-certbot-nginx
# If using Apache
sudo apt install -y python3-certbot-apache
# RHEL/Fedora
sudo dnf install -y certbot python3-certbot-nginx

Obtaining a Certificate

The simplest method uses Certbot's web server plugin to automatically configure your web server:

# For Nginx (automatically updates Nginx config)
sudo certbot --nginx -d example.com -d www.example.com
# For Apache
sudo certbot --apache -d example.com -d www.example.com
# Standalone mode (if no web server is running yet)
sudo certbot certonly --standalone -d example.com

Certbot will verify that you control the domain by placing a temporary file on your server and having Let's Encrypt retrieve it. If verification succeeds, the certificate is issued and installed automatically.

Where Certificates Are Stored

# Certificate files live here
ls /etc/letsencrypt/live/example.com/
# You will see:
# cert.pem       - The server certificate
# chain.pem      - The intermediate certificate(s)
# fullchain.pem  - Server cert + intermediates (use this in web server config)
# privkey.pem    - The private key (keep this secret)

Auto-Renewal

Let's Encrypt certificates are valid for 90 days, which is intentionally short to encourage automation. Certbot installs a systemd timer (or cron job) that attempts renewal twice per day:

# Check renewal timer status
sudo systemctl status certbot.timer
# Test the renewal process without actually renewing
sudo certbot renew --dry-run

If the dry run succeeds, your auto-renewal is working. If it fails, the most common causes are:

• Port 80 is blocked by a firewall (Let's Encrypt needs to reach your server)
• The web server configuration changed since the original certificate was issued
• DNS no longer points to this server

Manual Renewal

# Force renewal of all certificates
sudo certbot renew
# Renew a specific certificate
sudo certbot certonly --nginx -d example.com --force-renewal

Checking Certificate Expiration

Monitoring certificate expiration is critical. An expired certificate breaks your site for users and can disrupt API integrations.

# Check a remote certificate's expiration
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
# Check a local certificate file
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates
# List all Certbot-managed certificates and their expiration dates
sudo certbot certificates

Common TLS Misconfigurations

Even with valid certificates, poor configuration can undermine your security:

1. Allowing Outdated TLS Versions

# BAD: allows TLS 1.0 and 1.1 (vulnerable to BEAST, POODLE)
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# GOOD: only TLS 1.2 and 1.3
ssl_protocols TLSv1.2 TLSv1.3;

2. Missing HSTS Header

HTTP Strict Transport Security tells browsers to always use HTTPS:

# Add to Nginx server block
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

3. Not Redirecting HTTP to HTTPS

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

4. Weak Cipher Suites

Let Certbot or Mozilla's SSL Configuration Generator handle cipher suite selection. Testing your configuration with tools like testssl.sh or the Qualys SSL Labs scanner can reveal weak cipher suites and other issues:

# Install and run testssl.sh
git clone https://github.com/drwetter/testssl.sh.git
./testssl.sh/testssl.sh example.com

Security Checklist

Before considering your TLS setup complete, verify the following:

• All certificates use RSA 2048-bit keys or stronger (or ECDSA P-256)
• Only TLS 1.2 and TLS 1.3 are enabled
• HTTP automatically redirects to HTTPS
• HSTS header is present
• Certificate auto-renewal is tested with certbot renew --dry-run
• Certificate expiration is monitored (alerts fire at least 14 days before expiry)