Let's Encrypt - Finally, SSL Certs That Don't Cost a Mortgage Payment

Remember the dark ages before 2015? I spent thousands of company dollars buying SSL certificates from Verisign, DigiCert, and other certificate vendors who charged $200-500 per domain annually. Then I had to set calendar reminders to renew them manually before they expired and took down production.

I've been paged at 2am because someone forgot to renew a certificate. I've seen entire ecommerce sites go dark over weekend because the certificate expired on Saturday and nobody was around to fix it. Let's Encrypt ended that nightmare forever.

How Let's Encrypt Killed the Certificate Racket

Let's Encrypt launched in 2015 as a nonprofit run by the Internet Security Research Group with backing from major tech companies who were tired of the certificate tax. Mozilla, Google, Facebook, and others funded it because they knew HTTPS adoption was being held back by greedy certificate authorities.

The business model is simple: make certificates free and force automation. No more manual certificate signing requests. No more waiting 3-5 business days for validation. No more paying hundreds per year for the privilege of not having your site show scary browser warnings.

As of September 2025, Let's Encrypt serves over 650 million websites with 63.4% market share. They became the largest certificate authority in the world by doing the obvious thing: making certificates free.

The ACME Protocol: Automation That Actually Works

Here's what the ACME protocol does that the old certificate process couldn't:

The Old Way (Certificate Hell):

1. Generate a certificate signing request manually
2. Submit it to a CA with payment
3. Wait 3-5 business days for domain validation
4. Download certificate files
5. Install them manually on your server
6. Set a calendar reminder to do this shit again in 1-2 years
7. Inevitably forget and have your site go down

The ACME Way (Set It and Forget It):

1. Client requests certificate for domain
2. Let's Encrypt challenges domain ownership via HTTP or DNS validation
3. Challenge completes in seconds, certificate issued automatically
4. Certificate renews itself every 90 days without human intervention

The 90-day renewal sounds scary but it's actually brilliant - forces you to automate renewal, which you should do anyway. Manual certificate management is how production sites die.

Certificate Infrastructure That Doesn't Suck

Let's Encrypt runs a proper certificate infrastructure with multiple roots and intermediates:

Root Certificates:

• ISRG Root X1 (RSA 4096) - trusted by everything until 2030
• ISRG Root X2 (ECDSA P-384) - newer, smaller, faster

Current Intermediate Certificates:

• E7 and E8 (ECDSA P-384) for ECDSA subscriber certificates
• R12 and R13 (RSA 2048) for RSA subscriber certificates

All intermediates valid until March 12, 2027. Unlike commercial CAs that change their intermediate certificates randomly and break your chain of trust, Let's Encrypt publishes their certificate strategy years in advance.

Recent Changes That Actually Matter

IP Address Certificates: July 2025 update - you can now get certificates for IP addresses, not just domains. Useful for internal services and IoT devices that don't have proper DNS.

OCSP is Dead: As of August 6, 2025, Let's Encrypt killed OCSP because it was slow and leaked privacy. Now uses Certificate Revocation Lists (CRL) which are faster and don't tell the CA every site you visit.

No More Expiration Emails: June 4, 2025 - they stopped sending expiration warnings because if you're still relying on email reminders instead of automation, you're doing it wrong.

These aren't just technical updates - they're forcing the industry toward proper certificate automation practices.

Getting your first Let's Encrypt certificate is easy. Getting it to work reliably in production without breaking is where the real learning happens. I've deployed Let's Encrypt across hundreds of domains and learned every gotcha the hard way.

ACME Clients: Which One Won't Screw You Over

Certbot is the official client everyone recommends, but it's heavier than it needs to be. Works fine for single servers, breaks in containers unless you know what you're doing. The nginx plugin will rewrite your config files, which is great until it fucks up your carefully crafted configuration.

## This works 90% of the time
sudo apt update && sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com

## This is what you run when the above breaks your nginx config
sudo certbot certonly --webroot -w /var/www/html -d yourdomain.com

acme.sh is what I actually use in production. Pure shell script, no dependencies, doesn't try to be too smart. Supports 100+ DNS providers for automated DNS challenges.

Caddy is cheating - it handles certificates automatically. Great if you can switch web servers, but most of us are stuck with nginx or Apache.

Traefik is perfect for containerized environments. Automatically detects new services and provisions certificates. The learning curve is steep but worth it.

Domain Validation: HTTP vs DNS Challenges

HTTP-01 Challenge puts a file at http://yourdomain.com/.well-known/acme-challenge/. Simple but has gotchas:

• Requires port 80 accessible from internet (firewall nightmare in some orgs)
• Won't work behind load balancers unless you forward /.well-known/ properly
• No wildcard certificates
• Breaks if you redirect HTTP to HTTPS too aggressively

DNS-01 Challenge creates a TXT record like _acme-challenge.yourdomain.com. More complex but more powerful:

• Works behind firewalls
• Supports wildcard certificates (*.yourdomain.com)
• Requires DNS API access or manual intervention
• DNS propagation can take forever - plan for timeouts

TLS-ALPN-01 Challenge is niche and most clients don't support it properly. Skip unless you have specific needs.

Production Gotchas That Will Bite You

Rate Limits Hit During Testing: Let's Encrypt has rate limits of 50 certificates per domain per week. Hit this limit testing automation and you're locked out. Use the staging environment first:

## Always test against staging first
certbot --nginx -d yourdomain.com --staging
## Only use production after testing
certbot --nginx -d yourdomain.com

DNS Propagation Delays: DNS challenges can fail if DNS propagation is slow. I've seen this take 24 hours on some providers. Set appropriate timeouts:

## acme.sh with DNS challenge and longer timeout
acme.sh --issue --dns dns_cf -d example.com --dnssleep 60

Certificate Synchronization Hell: Multiple servers need the same certificate. Options:

• Shared storage (NFS, cloud storage) - works but adds complexity
• cert-manager for Kubernetes - automates everything
• Load balancer termination - centralize SSL at the edge

Renewal Automation Failures: Set up monitoring for certificate expiration. SSL Labs provides API endpoints for automated checks. Better to catch renewal failures early than wake up to a down site.

Container Deployment (Docker Compose Example)

This is the container setup I actually use in production:

version: '3.8'
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./letsencrypt:/etc/letsencrypt:ro
      - ./webroot:/var/www/html
    depends_on:
      - certbot

  certbot:
    image: certbot/certbot
    volumes:
      - ./letsencrypt:/etc/letsencrypt
      - ./webroot:/var/www/html
    command: |
      sh -c 'trap exit TERM; while true; do
        certbot renew --webroot -w /var/www/html --quiet
        sleep 12h & wait $${!}
      done'

Pro tip: The certbot container needs to share the webroot with nginx for HTTP challenges. Mount it read-only on nginx to prevent accidental modifications.

Multi-Domain Certificates and SANs

Let's Encrypt supports Subject Alternative Names (SANs) - up to 100 domains per certificate. Great for microservices with multiple subdomains:

## One certificate for multiple domains
certbot --nginx -d api.example.com -d app.example.com -d www.example.com

But be careful - if one domain fails validation, the entire certificate request fails. Sometimes separate certificates per service are more reliable.

Monitoring and Alerting

Since Let's Encrypt stopped sending expiration emails, you need proper monitoring:

## Check certificate expiration
openssl x509 -in /etc/letsencrypt/live/domain.com/cert.pem -text -noout | grep "Not After"

## Prometheus monitoring with ssl_exporter
docker run -p 9219:9219 ribbybibby/ssl-exporter:latest

Real talk: If your certificate renewal automation breaks and you don't have monitoring, you'll find out when customers start complaining about browser security warnings. Don't be that person.